Low-code: myths and reality

"Good" and "bad" tasks for Low-code

There are no rigid requirements for tasks suitable for Low-code, but there are certain markers that indicate that the system is suitable for specific tasks, and you can rely on them. And the first such marker is if the client is developing an application for the employees of their company, not a public service, not a social network or a news resource, but something that employees will use intensively and on a daily basis.

The next marker is the automation of routine tasks: Low-code solutions automate some sort of daily work, interaction and communication with their employees in such a formal way.

Low-code is also good if the customer's requirements are constantly changing (which is not uncommon in markets, including due to changing trends). You need some kind of dynamic, changing area. This is most often the case with a company's core business process of creating its product, which must adapt to the market, constantly change, and for which there are constant revisions.

Another important aspect is the automation of bureaucracy. Low-code replaces paper-based processes with an automated tool, solving all formal issues in parallel.

And the last marker is efficiency orientation. Low-code is good if the whole company's approach is focused not on perfect, but on timely and high-quality solutions.

At the same time, there are a number of markers that indicate that Low-code is not suitable. First, these are tasks of processing data arrays: in Low-code systems they are instantly reduced to code, and it is impossible to reveal the advantages of the system itself. That is why it is better to solve such tasks with software tools right away.

The next aspect is public services. For the development of an application intended for an unlimited number of visitors without registration, a low-code system is not very suitable. In terms of load volume, when we are talking about millions of users, the task will be too difficult because of the need for fine optimization and withstanding huge loads.

Another factor is unique and complex interfaces. If the main value of the application is complex interfaces (for example, a geological reservoir modeling system with a unique 3D interface and the ability to build these complex schemes), then a Low-code system will not be very suitable because of the specific requirements and the need for custom development. It is easier to approach then with a High-code approach.

Automation of technological processes that work not with people, but with some devices, including robots, will not be the most suitable case. Here, too, it is probably better to use specialized systems, because there will be a lot of development.

Specialized software such as graphic, text and music editors are not "friendly" with Low-code because of the peculiarities of the interface and focus on a single employee. And finally, for micro-businesses the use of their own development cannot be called justified either, such automation will not pay off due to the scale. In such cases, it is better to either work manually or take some box solutions. There may be exceptions to this rule, but in general this is the case.

Are low-code developers needed for low-code?

Advertisements often say that with the purchase of a low-code platform, business users will be able to create their own applications without programmers. This sounds very tempting, but, unfortunately, things are a bit more complicated in life.

The development itself and the complexity of the tasks itself is such that it requires competence in architecture, data structuring skills, analytical and sometimes even programmer's thinking. Business users do not always have all this. Of course, with experience and as they learn the tool, they will start to create better and better applications, but in general, this is not the main task.

Does that mean you shouldn't involve business users in development at all? Not really. There is a niche in which Low-code shows itself quite well. These are various local solutions. Quite a lot of people are familiar with corporate solutions like Excel, on which half of the business is based: when users make their own spreadsheets, keep their own records in them, and build their own processes. Low-code solutions are just right for such local developments. With their help it is easy to create some simple form without programming skills and use it in your department, for example. As the solution grows and is replicated throughout the company, it is worthwhile to involve professional low-coders who will be able to restructure the existing solution, make it better, more correct, and make it useful not at the level of a particular business segment, but at the level of the entire company.

You can't do without specialists with a technical background when working with Low-code. They are needed for development. But even a user without code writing skills is able to launch a simple business process, work with a simple data structure or launch an application for one department.

Myth: Low-code can't withstand high loads

One of the most common myths about low-code solutions is that such code cannot handle high load. Here we should probably first define what we mean by such a load.

If we are talking about systems with millions of users, processing terabytes of data per second, then Low-code is probably not the best solution. In these cases, you need subtle, complex optimization, which not every developer can do. You need a team of senior-level programmers who are able to solve such tasks.

But if we take solutions used inside a company, then, as a rule, the staff is not a few million employees, but hundreds and thousands. Modern low-code systems successfully pass tests for 10 thousand employees, but developers are gradually raising the bar and want to take the next frontiers. And it is quite possible to cope with these loads.

The important point is that when Low-code systems are already facing loads, a professional approach should be applied. At this stage it is necessary to involve competent devops engineers who will be able to configure infrastructure, data storage, servers and networks, redundancy, automatic scaling, make a fault-tolerant solution in case of any server outage. That is, this approach, applicable to high loads in conventional development, is worth applying to high loads and for low-code systems.

Also, we should not forget about the optimal writing and optimization of Low-code solutions, so that competent specialists check either the code part or the construction of the solution. With Low-code, as a rule, a problem can be solved in several ways, and you need specialists who are able to determine the right way. Of course, architects are also needed: they should be able to correctly build the structure of the solution, from which the whole development will proceed. And then you can resort to such a method as outsourcing heavy operations to external services. If we are talking about heavy data processing, it can be placed in a separate High-code service and integrated with the Low-code system, so as not to burden the main work processes.

Myth: A programmer will write faster

Another myth is that Low-code is unnecessary, a programmer will do everything faster and better anyway. There is an opinion that Low-code is just an arrangement of code pieces and, in fact, it doesn't bring any benefit or sense. And in general, if we look at the BPMN scheme, we see that it looks like a block diagram of some data processing algorithm. But still there is a key difference between them. It consists in the fact that the flowchart and the algorithm are oriented to work with data, with variables and operate at the entity level. A business process is focused on the interaction of people, on describing their reactions to external events.

Of course, algorithms can also be implemented via BPMN, but this is not practical.

Low-code systems bring new concepts in their designers, which the programmer involved in working with them begins to think with. When there was a transition from machine code, from assemblers, to high-level languages, a similar transformation took place. People stopped thinking in mathematical operations and memory cell addresses, and new concepts appeared: objects, variables, threads, channels. All these structures - they change the way we think, the very way we think when building our application. So Low-code strives to automate business tasks in a way that makes it easier for the developer to think. It is based on process and interface builders, which bring new abstractions into development and change the thinking of programmers.

Realistic expectations of Low-code

The main thing in working with Low-code is to form realistic expectations of this tool and use it competently and appropriately. In essence, Low-code is a framework for development, but unlike software frameworks, it uses not only code, but also visual tools to build its application.

Business users can solve some of their local tasks, and in the case of scaling up and moving to a more complex level, it is already worth connecting professional low-coders who specialize in the system. A competent approach to the IT infrastructure, to the very creation of your applications will allow you to build high-performance solutions and achieve results.

Another conclusion is that Low-code is not just an arrangement of pieces of code, but a platform that can give users new abstractions to think about when building their applications.

Vendor dependency in the case of Low-code systems cannot be avoided, but if you choose your vendor wisely, you should be fine. It is important to evaluate:

• how long the company has been in business;
• whether there are political and economic risks of its withdrawal from the market;
• what is the priority of the product in the company's portfolio.

CI/CD practices are now being introduced on the Russian market. They may not be as loudly talked about as trends in the Low-code market in general, but many vendors are trying to implement this approach to build not just some unimportant unloaded applications, but those on which a lot depends. In this case, due to a long and thorough testing process, you can be sure that the solution will work well. And when choosing for typical tasks, which are similar for most companies, it is quite possible to resort to box solutions, and for work with unique parts of the IT-infrastructure a competently chosen Low-code platform is very well suited.