Imagine for a moment that you did not work in software development, but were a domain expert in insurance policies. You work in the specialist department in an insurance company. Programming and software development are not your subjects at all, but you are very familiar with all the material aspects like policies, damages, liability and recourse.
Advertisement
Now you need a small piece of software: perhaps a simple tool to capture customer data more efficiently, or a report that allows you to better optimize your policies for the next year. Ultimately it doesn’t matter what it actually is. It’s all about something small and simple that makes life easier for you and your coworkers and drives your business forward.
Recommended Editorial Content
With your consent, an external YouTube video (Google Ireland Limited) will be loaded here.
Always load YouTube videos
Low-code and no-code: more harm than good?
How did you get this software? Sure, you can certainly go to the in-house IT department and ask nicely. If you’re lucky, your friendly coworker from IT will tell you it’s not a problem. She will take care of it and build it for you along the way. Of course, it turns out that unfortunately she doesn’t have as much free time as she thought, and maybe she didn’t know exactly what you wanted in detail.
This is the reason why the software cannot do the work it should do. But hey, don’t complain: at least you got something! It could have been worse: If you had met your grumpy coworker instead of the friendly and helpful coworker, he or she probably would have made it clear to you that there was no time for this kind of nonsense, IT was completely overloaded anyway. Was. There is no need to even come back without budget approval from 27 corners.
How great would it be if you didn’t need IT at all, but could create everything you wanted yourself – without any programming knowledge? Welcome to the world of low-code and no-code platforms!
C++ Programming Language: Extensions for Inclusive Scan in C++26The promise behind low-code
Everything I just told you ultimately describes the advertising promise of low-code and no-code environments. The idea behind this is that many processes in expert applications always run more or less the same: form entries, data retrieval from SharePoint, tabular or graphical visualizations – these are all recurring patterns. The platform now offers activities like building blocks, and you can use them to create your own application without knowing how the technical details work.
I tried it myself some time ago, together with a friend, based on the Microsoft Power platform, more precisely with Power Automate. It was about a simple use case: retrieving and displaying data from an HTTP API. However, after three to four hours, we no longer felt like it as we kept running into problems. Either we were both very incompetent (which I doubt), or our use case was a bit outside the intended use path. Finally, we brought on a colleague – a certified “Microsoft Power Platform Developer”. A developer for a platform that makes developers redundant – his absurdity is hard to beat!
Reality: More disappointment than benefits
Of course, this phenomenon is not representative of all low and no-code platforms. But this highlights a fundamental problem: Platforms make big promises and create high expectations – and the reality falls short: specialist departments can’t suddenly magically solve everything themselves. You can’t do without an IT department and developers. And they often save neither time nor money. In the worst case, exactly the opposite happens.
Why so? Programming means knowing a language. Whether you’re learning French or any programming language, you need to learn vocabulary and grammar, read, write, speak – and practice. The developers have acquired all this knowledge through years of hard work. And now there’s a forum that claims:
“You don’t need any of this!”
Golo Roden is the Founder and CTO of Native Web GmbH. He is engaged in the conceptualization and development of web and cloud applications and APIs with a focus on event-driven and service-based distributed architectures. Their guiding principle is that software development is not an end in itself, but should always follow an underlying professionalism.
Instead, you are given building blocks that you have to arrange. But these building blocks are often not sufficient to represent complex requirements. Professional and technical complexity remains – it becomes invisible. And recently when an application does not run well, race conditions occur or data traffic paralyzes the network, you will not be able to proceed without basic programming knowledge.
long term risk
Furthermore, many platforms are proprietary. As you develop applications based on such platforms, you create vendor lock-in. IT will be careful not to support such applications. It is very reminiscent of Microsoft Access, which still causes problems in many companies today. So the problem is not new – just the technologies have changed.
Furthermore, specialist departments often do not know what their processes look like in detail or what they actually require. That is why there are business analysts and requirements engineers who develop these requirements together with specialist departments. Specialist departments have technical know-how, but they are usually not prepared to apply this knowledge in a targeted and sustainable way in digital processes.
Despite all the criticism, low-code platforms clearly have their place. You can facilitate communication between the development and specialist department, for example by having prototypes made independently of the specialist department. For simple requests – like “fill out the form and send the data by email” – those may also suffice. However, I would recommend caution for more complex tasks.
appeal for cooperation
But the thing that bothers me the most about the whole topic is the “development vs specialist department”. This is not about “us vs. them”, and this narrative has never been constructive or effective, but always leads to fights and blame. At the end of the day, we truly succeed when we creatively bring together our different skills and knowledge and work together and in partnership toward a common goal: it’s about partnership on equal terms. Is. And low-code platforms should support this partnership, not divide it – but ultimately that’s what they do.
Long story short: seriously consider such platforms. Understand their limitations and rely on solid collaboration between the development and specialist department. This is the only way to ultimately benefit everyone involved – except perhaps the creator of the platform.
(rme)
This is the scam that empties bank accounts in Catalonia
