Low-code development from a developer's perspective — are there 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. Before you start looking for the dislike button, let's break down the most common misconceptions and assumptions.

In our view, the most common misconceptions are the following. Some people think that low-code means using ready-made products rather than a development philosophy.

By low-code, people mean advanced code-first platforms. Some colleagues even cited WordPress as an example. Low-code lacks proper DevOps (code review, versioning, deploy, etc.), proper code reuse, and other abstractions.

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

Developers are better off writing code that delivers immediate value than building visual builders. "Low-code does not need to be understood; it is just some kind of artifact.

We'll just 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?

By education I am a physicist and an entrepreneur. In the mid-90s I owned an ISP, and after that I held positions ranging from engineer at Beeline to managing partner at a company specializing in automation software development (my current role, which I have held for 7 years). And now it is interesting to think about what tomorrow will bring."

Starting with machine instructions, moving into procedural programming and giving up memory management, with the rise in the number of frameworks and the development of high-level languages, what comes next?

Will the level of development abstraction keep rising, and if so, how?

At the same time, demand for new products and automation is growing.

The shortage of specialists in the industry is easy to see in salary growth: it is outpacing productivity growth in IT.

In addition, the longer one development team stays on a project, the deeper it gets into operational support: more features generate more required fixes.

Development costs increase, and at the same time a conflict of interest appears: the business needs to change faster, while developers want interesting tasks.

But most business changes are uninteresting.

The IT industry has always responded to such challenges by raising the level of abstraction and simplifying development. The "assembly era" was replaced by the "C++ era," then came the era of high-level languages with complete freedom from memory and resource management, and after that the number of frameworks and libraries kept growing.

There are no signs that this trend will change.

Let's think about whether low-code can continue it.

Developers deliver the final value to the customer.

Element layout, new fields in entities, calculation logic, and integration flows — all of this is implemented through program code. Yes, it sometimes has settings that occasionally allow changes to be made 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.

Communication should take less time. And it would be nice if it were easier to make sense of your own code that perhaps no one has touched in six months. In code-first, these wishes are hard to fulfill.

Imagine that you deliver to the client not the final value directly, but a building kit for realizing that value. No, of course, you'll have to implement the initial functionality in your kit yourself for debugging purposes.

But at the same time you'll be able to create calls, functions, and components that...

In the vast majority of cases, they are self-documenting. Every component has settings that make it reusable.

Here it's important to note that code-first platforms also have many settings, and they are even distributed across components.

In practice, however, their use does not allow most of the operational work to be taken off the developer.

From this and other components, you can assemble fundamentally new value for the business.

Technically these are the same interfaces, business-process components, and integrations, but for the business this is fundamentally different functionality.

If some very exclusive logic is needed (one of the components is missing) and that logic clearly won't be reusable, you can insert the required component by writing a small piece of code. Unlike code-first systems, here you don't need to write a whole module or microservice — you insert the code into the right fragment without service boilerplate ("sugar").

Often such code is easily read not only by a developer but also by an experienced manager or business analyst, and consists of 2–20 lines.

When you face a new requirement, you either assemble new functionality in the kit you've already built, or you add activities and components to it if they're missing.

If you look at low-code development through the eyes of a code-first developer, what changes first of all is the level of component abstraction.

Besides the familiar services, libraries, and builders, there is one more, higher level of abstraction — the abstraction of business logic.

This holds true both when using ready-made LCDPs and when developing within the low-code paradigm.

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

Meanwhile, the vast majority of developer 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 face the following: they have to remember how everything is written here; it probably needs refactoring because code becomes outdated quickly.

But very few teams will volunteer for refactoring. And few business users will understand why a minor change was estimated at several days.

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 end 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.

The more expensive development becomes, the wider the gap between tech companies and everyone else. Everyone else is forced to plug into the ecosystems of the giants. And those ecosystems have very high productivity (because of their scale).

This alone pushes companies into someone else's ecosystem.

There was a time when IT costs were negligible.

But software is becoming ever more complex and varied, and the cost of IT infrastructure is a significant factor for startups and one of their main budget line items.

The more expensive IT becomes, the more substitutes there are for investment.

Organizations see digitalization as a well-paying investment.

The wave of digitalization will pass (all companies will be digitalized to some degree, and the rest will leave the market), and the deployed solutions will need to be maintained and supported.

With the ever-rising cost of IT, won't the question of finding other sources of income arise?

Won't the cost of IT at some point become so significant that it automatically cuts off most of the new — currently profitable — projects?