Request your demo of the Sigrid® | Software Assurance Platform:
As pressure increases to speed up time to market, organizations in almost every industry have caught on to the advantages of low-code platforms as a way to support rapid development. The opportunity to have non-technical business users (citizen developers) build applications increases the potential development capacity, reducing the distance between the requesting party (the business) and the supplying party (IT).
Low-code is a subset of technologies based on visual coding. Although it differs a great deal from traditional technologies, such as Java or C#, low-code development is still software engineering – and that means the same best practices for software quality management must be taken into account. Failure to do so can easily result in low-quality applications, presenting significant drawbacks to business stability and agility.
Speed at the cost of everything else
Suppliers of low-code platforms point to faster development speed as a key advantage, and it’s often stated that this speed takes precedence over quality. Many innovations built with low-code are often initially intended as temporary; if that turns out otherwise, the (faulty) thinking is that quality can be “added in” afterwards. Since the implementation of functionality with low-code technology yields only a small amount of code, the quality of that code could be (incorrectly) viewed as less important. Moreover, since little coding is involved, it’s often assumed that almost anyone without software development experience can work with these new technologies, thereby opening up a larger workforce.
However, I have some reservations about these sentiments that companies should consider before adding low-code to their technology stack. Let’s discuss some of them.
Low-code also means little code, right?
It’s commonly thought that only a small amount of code is produced when building software with a low-code solution. That’s correct if you see code as lines of text written in a programming language such as Cobol, Java or .NET. The trained software developer writes a program in readable text that’s then converted by an interpreter or compiler into machine language that can be executed by computers.
For software created with a low-code solution, a similar process holds, although most of the program is not written in readable text. Rather, the functionality is constructed from prefabricated and configurable building blocks using a graphical interface. These definitions are then interpreted (compiled) by the platform and translated into machine language. The construction of the program then requires that the (citizen) developer creates process flows by linking predefined activities and configuring them to create the required functionality. Only a small amount of traditional (text-based) code is added at specific places in the process flows to customize the implemented functionality according to the context of the specific company. This all can be considered programming as well, where the output is mostly process definitions and configuration of the activities as opposed to lines of readable text.
When we take this broader view of code, low-code certainly entails actual programming and there’s (a lot of) code being created – just not in the traditional, text-based way.
Technical quality is important for all types of software
If the products created through low-code development are considered to be code, the importance of software quality becomes much more important. All the (visually-created) code has to be maintained afterwards as well, as software systems are always subject to changes and extensions during the many years they’re in use following initial development.
When developing and maintaining software systems with low-code technology, the same software quality principles apply as for line-based languages. To name a few:
In addition, other software quality aspects, such as reliability, performance and security, must also be included by design for low-code software. Some of the features required for these quality aspects are provided by low-code platforms already, but others must be added separately by using standard, available building blocks. In any case, the developer must determine which requirements the application must meet and how these are then realized and guaranteed in the implementation.
Citizen developers must be trained
Before citizen developers can work with a low-code technology, they should be trained in working with the chosen platform. They also need to learn basic software engineering best practices to address topics such as software quality, automated testing and version management. But this training is often excluded from the low-code discussion. Even if it does take place, is it sufficient to enable citizen developers to reach the acceptable skill level? Does this also fit with their personal ambitions and areas of interest? Technical quality can’t be “added in” afterwards by an IT department taking over the technical maintenance and support of the application. And who will take care of the architecture when larger applications or a landscape of applications are built?
There’s no such thing as disposable innovation
Low-code technologies are often used for innovations, but don’t think these new applications usually end up being temporary. And that’s a primary reason why their technical quality shouldn’t be considered any less important. In reality, new applications always seem to remain in use longer than anticipated. Over time, they continue to grow in both usage and functionality. It’s rare for implemented functionality to be phased out again, and replacing an application with something newer and better with the same functionality is expensive. It doesn’t add any real business value, either.
In the past, we had a similar development principle: prototyping. The idea was that a prototype of the desired functionality was built quickly to get fast feedback from the user or client. Once the specifications were made clear by means of prototyping, the “real” development could start. However, in practice, a successful prototype was often not thrown away completely, and many prototypes were converted into “full-fledged” applications. When that application grew over time in use and functionality, all kinds of shortcomings emerged. It turned out that requirements such as technical quality, automated testing, scalability, performance and security weren’t included “by design” and were thus insufficiently supported in the basis, leading to insolvable technical debt.
Don’t lose the low-code benefit
I question whether the speed advantage of low-code should be realized at all costs. Low-code development is a form of programming, which creates software artifacts that have to be maintained for the rest of the lifetime of that application. In the long run, low quality hurts both its stability and agility.
Can citizen developers create low-code business applications that meet the (implicit) quality requirements of the business? And what level of expertise and understanding of software engineering best practices do they need? My advice would be to address these kinds of questions carefully before you can ensure you stay ahead of any problems like the ones mentioned here. To start, feel free to have a look at these eight practical guidelines I’ve put together in a new eBook.
Many companies have just begun with low-code technologies, which means that problems may not (yet) have manifested. But we’ve already seen the first examples of the promised high productivity and agility unable to be realized. In other types of low-code, such as application integration (EAI) and data integration (ETL), it also took some time before the first problems with very large, complex and highly-intertwined systems arose.
My colleagues and I are ready to help organizations prevent quality issues with low-code applications – and make sure they’re positioned to capture the low-code advantage long term.
Author:
Senior Consultant
We'll keep you posted on the latest news, events, and publications.
