Low-Code from a Developer's Point of View – Are There Any Benefits for Engineers?

The level of code abstraction has been increasing. It started with machine commands, moving on to the procedural programming and abandoning the memory management, with growing numbers of frameworks and the development of high-level languages. So what's gonna happen next? Shall we expect even higher levels of abstraction, and if so, how would it be implemented?

At the same time, we're faced with a growing need for new products and automation. The shortage of IT specialists is reflected in the growth of wages: it's outstripping the growth of labor productivity in the IT sphere.

In addition, if a development team works on the project for a long time, it's getting super involved in project's operational support: multiplying features result in a growing number of necessary edits.

Development costs are increasing, and at the same time a conflict of interest occurs as the business has to evolve rapidly, whereas developers want more interesting and meaningful tasks. But the changes in business are mostly routine.

The IT industry has always responded to such challenges by increasing the level of abstraction and simplifying the development. After the Assembler era there was the Era of C++, that was followed by the age of high-level languages with a complete lack of memory and resource management – however, after that, the number of frameworks and libraries has only increased

There are no prerequisites for the tendency change. Let's discuss whether low-code will continue this trend.

When I come across the articles about low-code in Runet, I always see comments about the imperfections of a particular product (products). We will discuss products a bit later in this article, and now I suggest thinking about the low-code concept as a whole.

Developers deliver the final value to the customer. Elements in a layout, new fields in the entities, calculation logic and integration flows — everything's implemented via a program code. Of course, there might be settings that sometimes allow making changes without developers. But most of the change requests are still implemented by the developers.

Developers can have two major aspirations:

Fulfilling these aspirations is not easy in the code-first.

Imagine that what you deliver to the client is not the final value, but a builder for implementing this value. Of course, you will have to implement the initial functionality in your builder for debugging purposes. But at the same time, you will be able to create such calls, functions and components that are self-documenting in the vast majority of cases. And each component has settings that make it reusable.

Also it will be possible to create a fundamentally new business value based on the components you've developed. Technically, the same interfaces, business process components and integrations will be used, but they will provide a fundamentally different functionality for the business.

If there is a need for an exclusive logic (one of components is missing) and this logic will definitely not be reused, you can insert the necessary component by writing a small piece of code. Unlike the code-first systems, there is no need to write an entire module or a microservice in this case — you will insert the code into the relevant fragment without the service binding. As a rule, such code is easy to read not only for developers, but also for experienced managers or business analysts and consists of 2-20 lines.

When faced with a new requirement, you either make a new functionality in a ready-made builder, or add the missing assets and components to it.

If you look at the low-code development from a code-first developer's perspective, you'll first note a different level of component abstraction. In addition to the usual services, libraries and builders, there is another, higher level of abstraction – level of the business logic.

This is true both when using ready-made LCDP, and when working on development in the low-code paradigm.

When discussing the low-code, I repeatedly notice that most people think that low-code is just a highly flexible system. For example, Bitrix – as "there you see the business processes and spreadsheet modelling" – or WordPress.

LCDP is a platform where everything is based on a builder. Because, if not, the platform maintenance will shift towards the code-first sooner or later.

I would single out the following LCDP criteria.

I will give some of your favorite examples.

There are also borderline cases. For example, Pimcore, which is a low-code platform in terms of the front, workflow, modeling of information models with calculated fields (with some reservations, but that's not what we discuss in this very article). If you try to do something outside the established framework, you'll be forced into a typical maintenance of monolith system.

Or the same old Bitrix. It is convenient for modeling data and building business processes, into which it is possible to pack the PHP code in the low-code style (i.e. without long initializations), if necessary. However, a huge number of boxed features that don't comply with the LCDP style, and the lack of advanced low-code tools in other parts result in a standard code-first.

In short, if someome says they've "tried a low-code platform and failed", I suggest that you get into the details. Probably:

This is a myth. These components are available on the vast majority of platforms. Many (Mendix, Pega) have introduced their own CI with low-code elements.

Although, of course, it is not always easy to carry out a review. While there are no problems with the code of components – everything is similar to the traditional code-first when it comes to what you can do with a builder…

Imagine that you developed a shoot and walk game on Unity, changed the walls, added mountains, and then saved the changes and sent everything for review. It is clear that you will not versionize every single change, and you will group changes into versions, and understanding them can be extremely complicated. Especially when it comes to visual changes and code inserts. This complicates the review process in the sense that it increases the number of changes per commit.

Reusability is not a point of concern as well: you can use the existing processes as subprocesses, or call one job from another, etc. If you're aiming at good results, reusability won't be a problem.

Developers are usually not enthusiastic about getting things done simply by clicking the mouse. Meanwhile, developing software is not rocket science, but mostly routine – the exact routine you want to do away with as soon as possible.

As you work on a project, you have a very limited number of tasks to choose from. The chances of getting something exceptionally interesting and creative are close to zero (this implies that someone else will have to do the boring stuff, and everything we're mentioned before will be re-assigned to your poor colleague). It is almost impossible to avoid all minor, and sometimes very similar and annoying tasks altogether. Just because someone has to do it.

How does LCDP help change the situation? You won't get rid of boring routine tasks and they won't even get less numerous, but instead of wasting hours on them, you will be able to tackle them much faster or even assign them to a non-developer. Why write another system integration, if you can implement it faster with ETL solutions? Why spend the whole sprint on making a new screen, if can be managed by a designer?

The faster you complete routine operations, the more time you have for something interesting. Moreover, the number of interesting tasks will increase statistically as the routine work will become shorter.

And what about truly gifted developers? Those who cope with most difficult tasks in a fast and elegant way?

Having completed a task for writing a code and having received a change request half a year later, they have the following problems to tackle:

But not every team would go for complete refactoring. And not every business user can understand why making a minor edit will take several days.

What is the result? We wanted to write an interesting code, but after a while we get stuck in a rut. We are left with the routine and regrets about the jobs done as they do not look nice anymore.

But if you think and develop in low-code paradigm you can not only provide more than faster solutions of routine tasks. Refactoring is performed not at the level of end values, but at a higher abstraction level, which is the builder component implementation level. As a result, you think and design more. You take control of most areas, and it's harder to make a poorly supported task in LCDP as such things as a bad naming or a bad logic can be detected even by non-developers. The approach itself makes you think in abstractions.

You can give up imagining the future of development if you assume that:

Let's try one thought experiment and guess if it is possible in real life.

My recommendation to developers is to pay closer attention to low-code and at least perform several tasks on any of these platforms – just to get some new personal experience.

We should understand the scope of applicability, see a cross-section of current opportunities and learn something new, because, as we're engineers, we should be able to look at new technologies from the point of view of their applicability. Maybe, you won't find any LCDP to help you solve your problems, but at least it may be useful to explore this trend to improve your engineering proficiency.