In the previous article devoted to using the low-code in enterprise solutions we've been talking about business. However, most of Habr users are engineers (thanks, Captain Obvious!), and in the comments to the article we came across a justified number of typical objections to LCDP (low-code development platforms) use. And while those who've never heard of the Dunning – Kruger effect are almost clicking a Dislike button, let's analyze the most common misconceptions and ideas.
In our opinion, the most common misconceptions are as follows:
- Some people think that low-code is the use of ready-made products (and not a development philosophy).
- Low-code is perceived as advanced code-first platforms. One of my colleagues even gave WordPress as an example.
- Low-code does not provide for standard DevOps (code review, versioning, deploy, etc.), a standard code reuse, and other abstractions. And low-code is normally applied in some typical solutions (for which no-code is intended).
- Developers are better off writing a code with an actual value, rather than developing some builders.
- "Low-code is often incomprehensible, now it's a thing of the past. We'd rather code as usual." However, some developers still don't have a clear idea even about the DevOps and think it's a matter of role. So the situation with low-code is not unique.
Why did we raise the topic of low-code and IT industry development prospects? I graduated at Physics and Entrepreneurship. In the mid-90s, our executive partner Andrey Putin owned the ISP Internet provider, and after that he held different positions starting from an engineer at Beeline to a managing partner of an automation software development company. On the basis of his experience he tried to predict what will the future be most likely.
A Few Words about the Current Situation in the Industry
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.
Is Low-Code a Philosophy or Not?
When we come across the articles about low-code in Runet, we always see comments about the imperfections of a particular product (products). We will discuss products a bit later in this article, and now let’s start with thinking about the low-code concept as a whole.
The Code-First Philosophy
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:
Is it possible that we only write an interesting code whereas someone else performs all the routine operational tasks (like, move the button)? For the operating issues, they can turn to us in some cases, that should be getting less numerous in the future.
If we are asked to make some operational changes, they must be formulated clearly. We don't want to waste much time on communications. And we want a native code, that presumably has been unchanged for like six months, to be more comprehensible.
Fulfilling these aspirations is not easy in the code-first.
The Low-Code Philosophy
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.
It's important to note that code-first platforms also have multiple settings that are attributed to individual components. However, in practice, their use does not help reassign most of the operational work performed by the developer.
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.
Low-Code is Often Confused with Advanced Code-First Platforms
When discussing the low-code, we often 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.
We would single out the following LCDP criteria.
The system core only includes the builder elements and everything related to it, i.e. you do not have to use the code-first approach to implement functions LCDP is designed for.
In the graphical editor you have the possibility to insert a code where you need it. And in some platforms, you can slightly redefine the code of the current component.
Some of our favorite examples incude
- ETL / ESB systems Talend and WSO2 are the low-code mechanisms for building integrations.
- Mendix, Pega, Appian, OutSystems, Caspio are the platforms for creating different class applications.
- Reify, Builder.io, Bildr are for building of the front.
- The newcomers of 2021 include Corteza (completely open-source, Go + Vue.js) and Amazon Honeycode.
- As for gamers – have you already checked the Unity and products based on it? Have you seen Construct?
- Examples from the Russian market are ELMA BPM, Creatio (a Terrasoft development) and Comindware, universal CUBA Platform, Jmix.
- Products of major vendors – Microsoft Power Apps, Oracle APEX, Salesforce Platform, IBM BAS, SAP BTP.
- Partial open-source are Builder.io (front), Bonita, Joget.
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:
- it wasn't LCDP;
- it was a bad LCDP (and that not a rare case);
- the team tried to write more code in LCDP than necessary. Instead of re-usability, there is one custom component with a huge piece of code inserted. We've seen that before!
Low-Code Does Not Have Traditional Control Tools Familiar to the Developer (Code Review, Deploy)
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 Better off Writing Code with an Actual Value, Rather Than Developing Builders
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:
- they have to remember how everything's organized;
- they face a strong need for code refactoring – a code quickly becomes stale and outdated.
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.
A bit of a tangent: many team leaders prefer the following approach: other team members are responsible for the implementation, whereas their job is to think. For sure, nothing good will come of it. Such team leaders often end up missing the code job, and the whole team becomes more fragile. The anti-fragility of such people is usually based on the fragility of other team members who basically work as typists. Both traditional and low-code developers are prone to that.
"Low-code is Often Incomprehensible, Now it's a Thing of the Past. We'd Rather Code as Usual”
You can give up imagining the future of development if you assume that:
- the number of tasks for developers will be multiplying as fast as the number of developers and development alternatives (taking into account the increasing labor efficiency);
- the business will be able to pay for the increasing development needs and not to go bust (i.e. the ROI in IT will always be positive);
- other types of investments will not compete with investments in the IT sector.
Let's try one thought experiment and guess if it is possible in real life.
The Number of Tasks for Developers Will Be Multiplying As Fast As the Number of Developers and Development Alternatives
Now the shortage of software developers in the world is about 10%. I can't foresee the future, but I can imagine the conditions to maintain this deficit forever.
First, the productivity of developers should not increase to the extent that it can compensate for this deficit (i.e. by 10% in relation to the current performance).
Second, the number of developers should not outgrow the number of tasks. An additional requirement is that the number of development alternatives should not reduce this deficit.
And this contradicts the fundamental law of supply and demand, stipulating that supply and demand are always in equilibrium.
And what happens now?
- A huge number of people are either thinking of or are in the process of retraining to become IT specialists. According to surveys, every fifth developer has no a professional (higher) IT education and came to IT after completing some training courses. Let alone omnipresent programming courses as early as at kindergartens and schools and an ever-increasing flow of students of IT specialties in universities. IT tends to poach prospective specialists from other specialities. This race has entered a new spiral these days.
- Basically, that's the way the market for no-code solutions (which are direct alternatives for development) looks in the current reports of investment banks. And if you look at this list, you will see that the number of products is growing. Type names of any company plus "low-code/no-code" in a search engine and you will see that almost every company from the Russian Sber to the American Apple is looking for the ways to significantly increase the development productivity.
- After all, the labor market disequilibrium is evident if we compare the cost of IT manager (whos job description includes greater responsibility including the multiplication of business performance) and middle developer (who has significantly less responsibilities). The income gap is 3-4 times, which is not accidental.
With 20 million developers in the world, there is almost 1 mln new developers in the market per year coming from India alone (and the number is growing each year), i.e. there is a slight chance we'll overcome the shortage of developers in the future. Some people have more radical opinions. For example, Herman Gref, CEO and Chairman of Sberbank of Russia, is predicting the radical decreese in demand for developers, or a German futurist Gerd Leonhard – he thinks that in 10 years all developers will lose employment.
The Business Will Be Able to Pay for the Increasing Development Needs and Not to Go Bust
The growing cost of development leads to a wider gap between the tech companies and the rest. The latter are forced to integrate into the ecosystems of tech giants. And such ecosystems are highly productive (due to their size). This in itself forces companies to join some external ecosystems.
Some time ago, the IT costs were insignificant. But the software is becoming more complex and diverse, and the cost of IT infrastructure is an important factor for startups and one of the main budget categories. The more expensive the IT is, the less competitive it becomes in comparison with other investment options.
Other Types of Investments Will Not Compete with Investments in the IT Sector
Why is there so much money in IT now? Organizations consider digitalization as a profitable investment. As long as the digitalization wave comes to an end (all companies will be digitalized to some extent, others will simply leave the market), it will be necessary to accompany and support the solutions applied. With the ever-increasing cost of IT, will the search for other sources of income become a challenge?
Will the cost of IT become as high as to automatically eliminate most of new (and currently profitable) projects?
Our 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.