3 best practices for healthy low-code applications

How to capture and maintain the advantages of visual technologies

Share this:

The tasks of IT-managers are diverse and challenging. These tasks include attracting and retaining the right people, selecting the right technology, delivering more with the same or fewer resources, dealing with all the political factors within their organizations, and respecting predefined targets and visions. You may find yourself facing these same challenges. The good news is that there are plenty of companies whose missions are to help. If your goal is to create software faster with a minimum amount of coding, then there are a number of low-code or no-code platform vendors who can bring some relief. Since their platforms provide visual composition possibilities, I’ll refer to those platforms as visual technologies.

Although the promise is compelling, there are a few important things to consider with regard to applying visual technologies. My colleagues and I at Software Improvement Group (SIG) recognize this, based on the many client projects we have executed. SIG has analyzed billions of lines of code, thousands of software systems, including the development teams that created and maintain them. We measure the underlying facts and provide clients with objective and impartial assessments to help management tackle their challenging software-related issues. This includes the analysis of many software systems implemented with visual technologies.

Based on our experience I’d like to share 3 best practices to help you take advantage of the promise of visual technologies while avoiding mistakes and poor implementations.

Best Practice #1: Understand the level of complexity involved, the importance of reviewing and customizing configurations, and embedding code to implement a system

This common misconception emerges like this: The sales department of a visual technology vendor says that with their solution, only a minimal amount of coding or even ‘no coding’ is needed. Strictly speaking, this is actually true. The misconception, however, arises when the previous statement is interpreted to mean that less or no code equals little and very simple work needed. The fact remains that the more complex the requirements, the more complex the implementation.

With visual technology frameworks, one has to (1) create visual structures, (2) review and customize configurations, and often also (3) add embedded code to implement a system. Creating visual structures can be done quickly, but it is typically just a tiny portion of the system implementation effort, especially with complex, industrial systems. The other types of labor intensive tasks (see points 2 and 3 above), are often underestimated and/or overlooked.

Best Practice # 2: Hire specialized and experienced developers to design your low-code apps

Once you have decided to use a visual technology platform, you also have to recruit people for development.  Often, less experienced programmers are chosen to work with visual technologies.This happensbecause it’s assumed that many of the difficult coding development aspects are handled by the technology itself (see also best practice # 1). At SIG, we have seen this misconception lead to below average outcomes in some client projects.

The knowledge of a less experienced programmer is, however, not sufficient for working with visual technologies. In addition to writing embedded code where needed, a visual technology developer must be able to (1) create visual structures, (2) understand the default behavior of the visual elements, (3) review and change the default configurations, and (4) understand the ripple effects of configuration changes – as well as what’s happening behind the visual curtain. Putting experienced and capable people to work with visual technologies can therefore help to avoid the accumulation of technical dept, which over time, might cause your project to be unsuccessful.

Best Practice #3: Secure alignment between business and IT through well documented business requirements

It’s often assumed that business stakeholders themselves can perfectly specify what they want in a visual technology tool. While it’s true that certain business-related views, like high-level business processes, are easier to express with visual technologies, those views do not yet include all the necessary details of a system’s implementation. These details are added later by designers and developers through numerous configuration settings and often coding. The bigger and more complex the system to be implemented, the more such configurations and coding are needed. These additional configurations and code parts must respect and align with the business requirements. The requirements should therefore be documented and shared.

At its core, software development remains a decision-making process. In this process, management decisions have to be respected and enriched with technical (architecture and implementation) decisions. This nature of software development is independent of the chosen implementation technology and therefore also holds true for visual technologies. There will always be a need for a certain type of handover between business and IT since the type of decisions involved cover a very broad spectrum. Let’s accept this and strive for a better business and IT partnership.

Conclusions

One should precisely understand the type of work and knowledge needed to build software systems with visual technologies.  This will enable you to avoid the related risks and use visual technology platforms to their full potential.

In addition to the three best practices described above, other relevant ones might exist. Which one would you add? Can you relate to the ones described? Do you have some thoughts that could further enrich the discussion of this topic? Please do let me know!

Related resources