Low-code platforms have been around for some time now. Indeed, it’s great to see their rapid success and how quickly they enable some applications to be made.
Some cynics will say that it’s not all that different from claims made during the ‘90s of some fourth generation languages and some later BPM vendor claims. In fact, the cynics may be right, although of course technology has progressed quite a bit in 25 years. But is there truth in the story that low code is better code?
The idea behind low-code is, of course, that people with a deep understanding of the business are best suited to create certain applications. This may very well be true for some applications, and the success of low code proves this. The challenge is that these people don’t necessarily have the same level of understanding of software engineering. This may lead low code to become overly complex, difficult to maintain, architecturally convoluted, as well as a whole host of other issues. As software engineering is a skill that can be done (very) well or (very) poorly, low-code development can also be done poorly. Very small, simple low-code apps will typically be higher in quality, much like very simple coded apps will be high quality. In our research, we see that architectural issues often come to surface, not surprisingly given the skillset of the developers and the potential complexity that can emerge.
Also, for many business problems, we do have to face the reality that coding sometimes has to become very complex, and not because the programmers don’t understand the business. Some logic simply is very complex, and it can only be automated with something that somehow mimics this complexity. Trying to create such an application with low-code will lead to very complex low-code as well. Moreover, it may prove to be impossible to use low-code in that situation. Try building an entire ERP system in low code, and you’ll find it’s better to use code for the core part; low-code may work well for some of the process parts.
In our first annual Benchmark Report, published in September 2019, we observed that software quality, in general, is increasing. The good news for low-code is that this is partly due to its own adoption. This doesn’t mean all low-code is of high quality; rather, it means that people have begun to use low-code more and more in smaller applications with limited complexity – exactly the areas where low-code is best suited. This is good news.
However, given the potential engineering pitfalls and the users’ lower level of software engineering skills, low-code probably needs quality monitoring even more than lined-based coding efforts. (By the way, my colleague, Rick Klompé, has put together some useful guidelines on how to stay on top of this.)
So, is low-code better code? I’m sorry to say, it depends. Carefully consider whether low-code is the best option for your project. And when you do, apply it right. If you apply it right, it can be a great benefit.
Monitoring quality is important, and low-code does not automagically protect you from doing things wrong. In sum, and to answer the original question: low-code can be better code, but it’s most certainly not a law of nature.