Low-code development from a developer's perspective - are there any benefits for engineers?

Low-code is something you can fail to grasp, some kind of artifact.

Reading time: 12 min. In the previous article about low-code in enterprise solutions, we addressed business readers.

However, on Habr, most users are engineers, Captain Obvious, and in the comments on the article I saw a fair number of typical objections to LCDPs, low-code development platforms. And while those who do not know about the effect

Dunning-Kruger effect aside, since some are already looking for the dislike button, let's break down the most common misconceptions and ideas.

And in general, low-code is for some standard solutions, which no-code is meant for.

Developers are better off writing code with ready-made value than building constructors. "You do not need to understand low-code; it is some kind of artifact. We will keep coding as usual."

However, some developers still do not fully understand DevOps and think it is a job title.

So the situation with low-code is not unique.

Why did we decide to raise the topic of low-code and the future of the IT industry?

Developers deliver the final value to the customer.

Layout of elements, new fields in entities, calculation logic, and integration flows are all implemented in code. Yes, it may have some settings that sometimes make it possible to make changes without involving developers.

But most change requests are still handled by developers. And here developers may have two wishes.

How can we write only interesting code and hand off the boring operational tasks ("move a button") to someone else? Let people come to us for operational matters only in rare cases, the number of which should ideally keep decreasing.

If we are asked for operational changes, let it be done more specifically.

In short, if you hear, "we tried a low-code platform and nothing worked for us"

You will find these components in the vast majority of platforms.

Many (Mendix, Pega) have their own CI with low-code elements. Although, of course, review is not always easy.

If component code is clear, it works the same way as in traditional code-first. But as for what you can do in a builder... Imagine you built a Unity shooter, changed the walls, added mountains, then saved it and sent the whole thing for review. Obviously, you would not version every wall change, and you would end up with huge change sets that would be quite difficult to understand.

All the more so when it comes to visual changes and code inserts.

The review process becomes more difficult as the number of changes in a single commit increases. Reusability is also usually fine: processes can be used as subprocesses, and one "job" can call others, and so on.

If there is a desire to do it well, reusability will not be a problem.

Developers usually look down on the idea that they could build something by clicking with a mouse.

Meanwhile, the overwhelming majority of a developer's tasks are not rocket science but routine work.

The very kind you are not interested in and want to get rid of as quickly as possible. Within a project, your choice of tasks is limited. It is unlikely that only interesting and creative work will come your way (which implies that someone else will handle the boring tasks, and then everything said above applies to that poor person as well).

It is almost impossible to avoid small, and sometimes repetitive, boring issues altogether.

Simply because someone has to handle them.

How will the situation change within an LCDP?

Boring tasks will not go away and will keep appearing just as often, but instead of spending countless hours on them, you will be able to finish them many times faster or even hand them off to someone who is not a developer.

Why write yet another integration between systems when you can build it faster with ETL solutions?

Why fill a sprint with building a new screen if a designer can click it together?

The faster you complete boring tasks, the more time you free up for more interesting ones.

Moreover, statistically, you will get interesting tasks more often, because the break for routine work will shrink many times over. And what about truly talented developers, the ones who can solve any of the hardest problems elegantly and quickly?

After delivering a task as code and then receiving a change request six months later, they run into the following: they have to remember how everything was written here; it should probably be refactored, because code becomes outdated quickly.

We wanted to write interesting code, but after some time we are not writing anything interesting.

What remains for us is operations and a guilty conscience for the fact that things here are already not very pretty.

If you think in terms of an LCDP, it is not limited to just faster handling of routine tasks.

Refactoring happens not at the level of final business value, but at a higher level of abstraction, at the level of the builder component implementation.

As a result, you have to think more and design more.

Fewer areas remain outside your oversight, and creating a poorly maintainable task in an LCDP is much harder because even non-developers can spot at least bad naming or flawed logic.

The approach itself makes you think more in abstractions.

Many team leads solve this problem for themselves like this: other team members handle implementation, while they do the thinking.

This leads to nothing good.

Such team leads often start missing code, and the team as a whole becomes more fragile.

The antifragility of such people is ensured by the fragility of other team members, who act as typists.

Both traditional and low-code developers can be susceptible to this flaw.

An additional condition is that the number of development substitutes must not reduce this shortage. That contradicts the fundamental law of supply and demand, because demand is always balanced by supply to an equilibrium point.

A huge number of people are either thinking about retraining into IT or are already in the process of retraining.

According to surveys, one in five developers has no specialized education and entered IT after completing courses. And that's not counting the pervasive programming courses starting as early as kindergarten and school, and the ever-growing stream of IT-major students at universities. IT is starting to take potential specialists away from other professions.

And if you look at this list, you will see that the number of products is growing. Search for "the name of any low-code/no-code company"

- and you will see that almost everyone, from CIS's Sber to America's Apple, is thinking about how to significantly increase development productivity. After all, labor market imbalance is easy to see in the ratio between the cost of managers, who carry greater responsibility and on whom multipliers depend, and mid-level engineers, who carry much less responsibility.

The income gap is 3 to 4 times, and that is no accident.

With 20 million developers in the world, just

India supplies the market with a million developers a year (and that number grows each year), meaning there is some probability that the developer shortage may not persist in the future.

There are also more radical opinions: from

German Gref, for example, or a futurologist