What is a typical low-code solution?

While there are a lot of low-code solutions in the market and they may significantly vary in functionality and implementation details I’d like to start with highlighting the most recognizable features standing low-code solutions out from the other family of software products:

provide an environment for automation rather than implementation of specific business processes. Might be used for automation of variety business process typically restricted by some industry (banking, insurance, e-commerce and etc)
introduce a clear distinction between environment and configuration in terms of development and deployment. Often, configurable part is another piece of software that runs on top of the platform. Thus, the platform acts as a virtual environment that is capable of loading and interpreting a prepared and validated configuration
provide a sophisticated and advanced toolkit for preparing configurations, which typically contains tools for building business entities, UI and store modeling, visual modeling tools, deployment tools

Why low-code solutions are so popular?

Before we discuss what is wrong with low-code solutions, lets first understand why they have become so popular.

Here are my observations after years of working with low-code solutions:

configuration of simple and medium-complex business processes looks much more efficient compared to classical software development. Especially in projects with a high frequency of changes and/or with a lack of analysis (almost all projects). I intentionally wrote “looks” rather than “is” because most projects tend to become more complex than originally intended, and business processes that were simple or medium become very complex over time
they are very handy for selling. It’s very effective to demonstrate to potential customers how easy and cheap it is to build new functionality without a single line of code. Initially impressed decision makers on the customer side become more inclined to close the deal. Even if there is a tech geek who drives everyone crazy with questions like “how would we configure this and that… and what if we set up this or that…. ?” the “danger zone” questions could be settled with answers like “it’s a matter of configuration…” without further details or with some explanations on high level of abstraction. It’s not very typical when a potential customer asks for some quite complex configuration
rating agencies tend to give high marks to low-code solutions for their flexibility without taking into account their shortcomings. Of course, this increases the confidence of potential customers. The price of this flexibility isn’t on the surface
the idea of low-code solutions gives the impression of being able to significantly reduce the development team by transferring most configuration functions to analysts and consultants. Thus, increase efficiency of delivering new functionality to end users
low-code solutions are easily sold by architects to management. It’s presented as something that solves all current problems and gives unlimited levels of flexibility and efficiency. It should be noted that software architects love any universal all-in-one solution because it satisfies their need for a unified theory of the universe

Standardization vs Freedom

The key to understanding low-code solutions and why they occur is realizing the fact that flexibility that general-purpose programming languages give us is also a source of inconsistency, inefficiency and instability in the software. Why? After all, a programming language, like a natural language, allows us to solve the same problem in billions of different ways. Moreover, each developer expresses his or her personality when solving a problem (writing a diary, according to Chuck Palahniuk). Thus, the quality of code and, as a consequence, the quality and reliability of software depend on the personality of the developer. This become especially critical when internal development processes aren’t perfect o when a key part of the team changes

The software industry has come up with a solution. Standardization as a way to reduce personal influence. Many different approaches to implementing standardization has been proposed over decades, and implemented with more or less success. Code and architecture patterns, code templates, commonly admitted best practices, technical documentation, code review. But as long as people write code, there will be room for freedom (read for bright new ideas as well as ugly bugs).

So, low-code solutions are another level of standardization, which in its extreme form aims to completely eliminate personal influence on the final product. However, the more complex problem we solve, the more original and subtle approach will work. Thus, while low-code helps to increase efficiency in developing simple and medium-complex problems, it introduces significant limitations in solving complex problems.

Inventing the wheel

As stated above, low-code solutions usually provide a special set of tools for configuration. How sophisticated and advanced this toolkit is depends on the specific solution, but it cannot be simple and usually requires a lot of effort from the platform development team to create and maintain. Moreover, the more complex problems the platform is intended to solve with configuration, the more complex the toolkit becomes over time.

It’s obvious that any highly configurable environment needs a way to describe business rules. Up to some point, it is possible to use predefined configuration features available through UI or config files. But sooner or later, a low-code solution adds support of some sort of programming abilities. It can be very simple and limited language, but having even the simplest internal programming language takes the platform to another level of complexity. We aren’t considering the invention of a new programming language, although I’ve seen some. It could be some sort of json(xml) language or any scripting language (js, groovy) implementing on top of production-ready libs. But allowing users to write even simple code within the configuration increases the number of edge scenarios, side-effects and vulnerabilities to be aware of.

In addition, writing code in a simple text editor isn’t convenient and modern, we are used to syntax highlighting, code completion and other fancy staff. Yes, this is already the way to create IDE-like instrument. Needless to say how much effort a company has to put into building a modern advanced configuration tool with support of any simple language from scratch. In this way, the company developing low-code platform becomes a competitor of software giants, that have been working on IDE products for years. In my experience, most low-code solutions remain either with a very poor set of tools or with a number of low-quality and buggy features with many strange limitations that you should be aware of.

The most difficult part of the configurable platform is the implementation of the user interface and data stores configurations. As for data stores, it can be implemented as schema-free storing, but with full or partial loss of control over data consistency. Attempt to implement configurable relational store inevitably leads to either many problems with structure modifications (dynamic DDL) or inefficient SQL queries in case of modelling data schema without physical data-model modification (some predefined tables store all the data in a special universal format).

User interface configuration is another aspect to pay special attention. It goes without saying that there’s not much point in a low-code solution that doesn’t provide the ability to configure user interface. But think for a minute about how difficult the challenge is to create a highly configurable and advanced UI at the same time. Moreover, the user interface is the part of the software that changes most frequently and where the most unexpected features are requested. One, by the way, not the worst approach I’ve encountered is to provide very limited configuration abilities with support for a set of predefined components and find a way to convince users that they don’t need more. Again, the problem of limited UI configuration is not something that can be easily identified by a potential customer in the pre-sales phase. And here I’m not talking about mobile apps.

Now let’s talk about runtime. Any low-code solutions provide the ability to build business functionality without writing a lot of code. But how can end users use the configured business processes and entities? This is where a runtime environment comes into play. The stored and validated configuration has to be interpreted by a special part of the system, which in my terminology is called runtime. Runtime is similar to JVM that plays your Java code, but instead of java byte-code uses a prepared configuration in a predefined format. While I can think of solutions that make a process of interpretation as efficient as running compiled code, in most cases interpretation of the configured functionality has significant performance penalty.

Another problem is that runtime is usually part of the platform, making it very difficult or even impossible to optimize in place any problematic parts. Because of that performance problems are either solved on platform level (expensive and long) or not solving at all. The possibilities to solve problems of a particular configuration most likely just do not exist.

Even if the runtime in your solution is really matured, new major and minor versions will appear. Migrating to a new major version can become a nightmare if the configuration isn’t fully compatible with a new runtime. Also compatibility can be broken because of some bugs in the configuration tools. Needless to say, that the toolkit version and the runtime must also be compatible. The low-code solution provider must ensure backward compatibility or provide clear instructions and full support to customers in migrating to a new runtime and toolkit major version.

What about people?

After considering the most important technical aspects, let’s look at the people involved in the development and configuration of low-code solutions and try to highlight the general trends associated with them.

Platform development team

For most developers, it’s probably a dream job. Here’s why:

no direct contacts with customers
no details of specific business processes
no strict deadlines set and traced by customers
creative and interesting development tasks. Of course, writing business logic is not as exciting as some generic solution

Configuration team

Regardless of who configures the solution, they are likely to have the following problems:

platform isn’t stable and/or lacks critical features
the new version of the platform is broken and/or incompatible with the current configuration
if you are an analyst (consultant), you are probably not satisfied because the configuration is too technical for you. You can easily configure some typical things, but when you need to do something atypical or non-standard, you have to call for developers. You need to be aware of many technical aspects (know the built-in programming language, how to debug it, know its limitations and internal bugs)
if you are a developer, most likely you aren’t satisfied because configuration is too boring for you. No freedom in making technical decisions, no new libraries and frameworks, built-in language is too simple and limited, no self-development

Sales team

The platform is very easy to offer to potential customers and very good for demonstration. The answer to all the vague questions is “it’s a matter of configuration…”.

Customers

Everything is going well until the limitations become apparent. Feature requests for the platform are either too expensive or are part of next year’s roadmap. Deadlines and budgets may be exceeded due to unexpected constraints. Some features may not be possible to build and deliver because the platform “doesn’t allow this”

Business users

Configurable user interface is always less convenient and advanced. Some critical business functions may look strange and not intuitive due to platform limitations. Performance may not be perfect.

Summary

In this post I tried to give most of my personal impressions after several years of working with different low-code solutions. Being a skeptic about low-code solutions in general, I admit that they can be good for certain tasks and contexts. For example there are a lot of BPMN solutions on the market that are really good and do the job. Just don’t fall for marketing presentations promising to solve all your problems and raise your development efficiency to the next level. Low-code solutions are not a silver bullet. They have their pros and cons.

Being a low-code skeptic