Low-Code is promising to radically change the way organizations develop and manage their IT landscape. So far, there are many signs that this app development approach is delivering on this promise. Companies of all sizes are rapidly developing new applications and setting up their own Low-Code ‘Centers of Excellence’. The development platform market is projected to grow from USD 13.2 billion in 2020 to USD 45.5 billion by 2025 .
While we’ve seen many organizations implement Low-Code successfully, we’ve also seen some organizations struggle. It is definitely possible to have your internal employees develop innovative applications in a matter of weeks and solve issues in a matter of hours. However, to realize this ambition, you must manage your delivery carefully. If you rush into it, the most communicated benefits of Low-Code platforms can quickly turn into the most common pitfalls. Here’s a few we would like to call out.
Sliders, data tables, tab containers; Low-Code platforms typically come with a library of UI components that are common in most well-known applications. It’s a matter of dragging and dropping them onto your What You See Is What You Get interface and your screen is ready.
The components are based on best practices and updated when new trends emerge. However, the combination or limitations of elements might not deliver the user experience that your users need in their context.
As a concrete example, some platforms come with data tables that don’t allow in-line buttons. You are implicitly encouraged to present your Product Owner a table in which they have to select a row and subsequently scroll to the top to execute an action. In many cases, it’s possible to customize such an experience. In practice, it’s tempting to go for the plug-and-play option as ‘you don’t know what you don’t know’.
Low-Code is relatively easy. There’s no need to learn a new coding language, understand your IT infrastructure or even know what compilation means. This makes the approach very accessible to people without an IT background and no experience in developing software applications.
Automatically and in the background, all your configurations are translated into an actual programming or query language and database tables are created for your data entities. Both in the cloud and on-premise, there is an infrastructure that runs your software.
Without knowing how all the translations work, sub-optimal software code might be produced. This could lead to slow-performing queries, too many server calls, poorly structured database or even worse: the infamous spaghetti architecture.
An Agile way of working and Low-Code are a match made in heaven. The speed of developing and deploying Low-Code applications makes it much more feasible to act upon feedback and show results quickly.
It’s also easy to develop from a user story perspective. Most Low-Code platforms provide a data — logic — interface setup out-of-the-box, which makes it ideal to build a full user story as a ‘chunk’ of front-end and back-end components. Developing your sprint backlog is a matter of building story after story.
Functionally, this is great. Technically, it has some risks. Only focusing on the delivery of user stories might result in an inconsistent or non-existent foundation layer. Working on the data, logic and interface layers at the same time from a solely functional perspective could lead you to choices that jeopardize the stability, maintainability and reusability of these layers.
The expectation of fast delivery poses a second risk: no priority on testing. A slick demo of a Low-Code platform will always show you how quickly you can build functionality. It will rarely show you how to incorporate component testing, regression testing or load testing. While Low-Code does reduce the need for some tests due to its built-in quality checks, a complete lack of testing is not advised.
With the greatest benefits of Low-Code — its reuse of best practice components, its ease and its speed — some risks come along. When not appropriately applied, the approach could lead to poor user experience, low-quality products or below-par performance.
But, no need to be afraid! This article is not meant to scare you; it just needs to be emphasized that Low-Code has to be done right to give you its promised results. For each of the risks stated above, technical and non-technical mechanisms can be implemented to reduce or even omit the risk.
As an example, we have written several blog posts about how we execute our ‘Discover’ phase in projects [2, 3, 4, 5]. In this phase, we use extended Design Sprints to design the user experience before we use library components. This leads to a technology-agnostic design of the solution. To mitigate the other risks, we have carefully defined our ‘Develop’ phase. In this phase, we initiate the development with a development plan and a technical foundation plan. Our future articles will dive into these topics and describe how they help us to seize the great benefits of Low-Code.
Business Technology Consultant