I recently encountered the idea of Low Code/No Code Platforms in a client context and while my initial reaction has been kind of ‘No…please…No’, I became curious. Is my rejecting reaction just based on my bias as a software developer and code wrangler? Therefore I wanted to explore and understand this topic a bit better.

What are “Low Code Platforms”?

What do I consider low code application platforms (LCAP) in this context? Any kind of software development platform where the software is developed mostly using graphical tools. Not only for the UI but dragging and dropping the business logic onto some canvas instead of writing code in a programming language. Additionally, to support more complex scenarios, most platforms allow us to write some source code in a programming language. Often multiple deployment targets (e.g. mobile devices and HTML applications) or runtimes(e.g. JVM or .NET) are supported. Releasing into production often is just a mouse click away. Gartner predicts that until 2024 up to 65% of application development will make use of low code application platforms. Examples of LCAP are OutSystems, Mendix or Microsoft PowerApps.

The main selling point seems to be already in the name: low code - no code. What is it that makes the absence of source code so appealing?

The Secret Source

Aside from the actual application, source code is the most prominent artifact of software development and to a lot of non-developers it is also the essence of it. Movies come readily to mind, where some protagonists write an incomprehensible piece of code to save the world and along the way even hack some alien spaceships. The code displayed in such scenes is intentionally incomprehensible and I assume that for many people this gibberish seems to be the manifestation of the hard parts of software development, like a foreign language with cryptic symbols. At the same time causing admiration and awe but also being an insurmountable riddle, never to be solved. In these movies, only a special kind of nerd and/or scientist appears to be able to properly read and write it - hacking away on the keyboard at an incredible speed.

For most companies revenue is in some way coupled with the performance of their IT department, often to an increasing degree. And for managers without a software engineering background - and even for some with - their reality appears to have some similarities with these movies. They often do not fully comprehend how their developers work - and they might neither have to nor want to. But the speed their IT department can deliver software is an important criteria for business success. And this ultimately appears to be somehow entangled with and defined by writing this cryptic source code. On top of that a war for talent which makes these experts hard to find and rather expensive.

How tempting, how luring does the promise of low code, no code platforms sound in this context? Based on the advertisement, Low Code Platforms help companies to deliver value fast while reducing cost of ownership and allowing anybody with an idea to also develop and deploy the solution - no matter whether it is just a small app or a core service of your enterprise. The integration of any existing legacy software landscape is easy. The one-stop-shop for a company’s IT challenges.

Sounds like saving the worldcompany without the need to write source code! In the best case business people are enabled to develop the software on their own - thereby perhaps removing the slow and expensive software developers entirely from the equation? Count me in!

Challenges of Software Development

But is this really a substantiated assumption? Is the challenge that is constraining the business really writing the source code? Let’s look at other fields that include writing and some kind of source code: Is the challenge of becoming a renowned writer and author really ‘just’ getting the syntax and grammar right? Overall 9 out of 10 people are able to write, nowadays equipped with auto-correction and services like grammerly. We should all be famous authors by now. Applied to music, do all the available tools allow all of us to create good songs and symphonies - or do we still have the impression that making the effort of actually understanding music - either by formal education or informal by just investing time - would, in general, be a good and necessary foundation for success?

In my experience, developers rarely struggle with code, especially in times of modern IDEs like Visual Studio Code, Eclipse or IntelliJ that provide extensive auto-completion support. They will happily complain about missing syntactic sugar and repetitive boilerplate, but what they actually struggle with is the software design and expressiveness. The longer the software is in use and the more features are added, evolutionary architecture and refactorings come into play. These are mostly invariants to the programming language used, though - and likely will not disappear when switching from text into UI based input.

Low Code and Software Design

Software products don’t fail just because of ugly code. In my experience, when developers talk about this what they mean is lack of software design on multiple levels. The “big ball of mud” is easy to achieve but hard to get rid of. But the challenge here is again not source code but design, architecture, encapsulation, cohesion, coupling, naming, … In my opinion, low code platforms have a hard time eliminating this challenge. They can provide highly opinionated tooling and constraints to avoid some of the common pitfalls but as the complexity of the solution increases, the incidental and accidental complexity will evolve in roughly the same way as with an ordinary approach, as the challenges are almost orthogonal to the format of notation. Considering the lack of refactoring support and the coupling with proprietary IDEs it might likely become even harder to keep the complexity at bay.

Throughout the last decades, there have been various visual programming languages or even approaches like model-driven architecture. While some of them are well suited for their respective niche, none of these approaches has come even close to replacing general-purpose programming languages.

Low code platforms don’t provide a general solution as they fail to address the challenging aspects of software development. But are there circumstances, where they excel? What could be a sweet spot for low code platforms?

Low Code Sweet Spots

The challenges of software development increase over a products lifetime, driven by the incidental and accidental complexity of problem and solution. As written above, Low Code Platforms in the best case won’t make a difference but more likely will add additional challenges over time. But what if the problem is rather small, has a more or less fixed scope and a rather limited lifespan or audience? Some small dialog to allow customers to fill out a simple, limited form or a dialog for a back-office employee to edit some rarely used data? Or to provide a simple and small inspection frontend to an API based Microservices? In such circumstances low code platforms can make use of their strengths. Quickly developed and deployed apps that have a small blast radius and the software design aspects can be neglected in a sacrificial architecture style. In DDD lingo, these could be small applications in the supporting or even generic subdomains. If scope, audience or lifespan increases, though, it requires some courage to avoid a sunken cost fallacy and decide early to switch to a different approach and tech stack - something that should still be relatively cheap, as the blast radius should be small. This has to be navigated carefully as the challenges will accumulate slowly and, if not actively watched out for, be only discovered when it is already slightly too late.

Conclusion

Low code platforms might be a viable option, the smaller and short-lived the solution, the better. I would still recommend to avoid this for any larger solution or product, especially if it belongs to the core domain. It might be viable for rapid prototyping to quickly gather valuable customer feedback - if the team dares to throw it away afterward and start over with a standard, code-based approach if the prototyping phase ends.

Low code platforms are like a racing car with a good acceleration but a low top speed. It might be in the lead when entering the first curve on the track, but it will rarely if ever win a race over multiple laps.