Low-code and no-code (LC/NC) tool makers are facing an uphill battle trying to convince people, especially professional developers, to use or even just try their tools and platforms. A few platforms have made inroads into this market, but the majority of software development is undoubtedly still done by professionals writing code.
From the tool makers’ perspective, the lack of interest seems perplexing. Faster development, lower costs, fewer bugs, easier deployment, managed environments - why would anyone reject these utopian vision tool makers like to present? Why do so many rather continue their battle with difficult languages, complex bug tracing, and obscure environment setups?
I have been talking to developers, reading articles, and trawling discussion forums to get an answer to these questions and have collated some of the reasons brought forward.
It does not help their careers
Learning low-code tools can require a significant investment of time and effort, but there is little professional value in learning a specific LC/NC tool. Even in the rare event that a software development house uses a LC/NC tool, the skills an employee developer acquires by learning that tool will most likely not be required by the next employer.
Most development jobs demand in-depth knowledge and experience with widely used languages and frameworks and no low-code tool is as widely used as React, Angular, Python, Java, or C#.
Very few development jobs require knowledge of LC/NC tools and the likelihood that a developer will find a better job or earn more money knowing a LC/NC tool is very low. So, developers are better off spending time learning and perfecting one of the myriads of skills, frameworks, and languages that are in high demand on the job market.
Developers spent years learning how to write code
Almost 70% of developers who responded to the
If LC/NC tools actually deliver what they promise, then writing code to create applications will no longer be required in the future. Programming will move to a higher level of abstraction and applications will be assembled from existing components rather than coded. So, programmers essentially threaten to make their hard-earned skills redundant by using and supporting the increased use of LC/NC tools. It is therefore actually in their interest for LC/NC tools not to succeed.
Developers care less about speed
When developers work for software houses, they get paid to deliver code that has specific characteristics. These include being easy to read, testable, well structured, reliable, efficient, following standards, and so on. Developers who maintain even moderately complex applications will appreciate how important it is to make sure code is as simple as possible and easily understandable. These qualities are essential for code to be maintainable.
Code is usually reviewed by a more senior programmer who also cares about these qualities and reinforces an emphasis on them. They might have a higher interest in getting things done quicker than the developer, but they know that code that is buggy, inefficient, cryptically written, and hard to extend is hard to maintain.
This bad code can cause a lot of trouble and become very expensive down the line. While the speed at which code is delivered is relevant, the way the code is organized and written usually takes precedence over the speed at which it was delivered.
So, marketing the speed of development of LC/NC tools to developers may not actually have the anticipated impact.
Developers enjoy coding
People are vague and emotional. They have conflicting priorities, are often unsure, inaccurate, and lie. Often they don’t even know what they are doing and why they are doing it. People can be very confusing. Computers are much simpler. The computer simply follows the instructions it was given by the programmer and if those instructions are incorrect, the program fails. The precision in defining a set of tasks and seeing them done immediately and exactly gives many people a sense of security and joy.
There is a creative element in coding that many developers really enjoy. Programming is a very complex puzzle, full of brain teasers, spanning dozens of modules, multiple layers, and thousands of lines of code. A single web application can easily involve five or more different languages working together (e.g. HTML, JS, CSS, C#, SQL). Fashioning complex objects of interlocking moving parts, and watching them work in subtle cycles as they play out the consequences of the logic built into them can be fascinating, and bring a strong sense of accomplishment.
The reason why software exists is to make life easier and we fundamentally build software to help people do things better. Once you know how to write code - in any language - you can build anything you can imagine. There is joy in imagining something and then creating it from nothing, especially when it is useful to others and makes them happy.
Developers don’t choose tech stacks
The longer a developer stays on a project, the better they get at extending the application and the more efficient they become at finding and fixing problems. When developers leave their jobs, they often take intimate knowledge about intricate details of applications with them. This knowledge is very hard to regain and when such employees are replaced, the applications they supported often enter a phase of instability and sometimes even chaos. So, while software houses have an interest in stability software developers often only stay with one employer for a few years.
One strategy software houses employ to mitigate the loss of knowledge is to use technologies that are widely used and well known in the developer community. Using well-known stacks makes it easier to find skilled people to employ. It also helps those people learn the ins and outs of applications built with them. Developers may be influencers in the decision of which technologies to use for a project, but it is commonly senior engineers or even management who decide on the stacks using these criteria. Marketing LC/NC tools to developers may hence miss the mark.
Betting on a tool is risky
Clients tend to be hard to pin down on where they might take an application in the future. This is understandable since the future is very hard to predict. So, application owners need to adapt to changing needs to ensure the commercial success of an application. This often means amending business models and changing the technologies that enable such models. Experienced developers know this and like to build open systems that can be adapted to changing needs in the future. The best way to create such adaptable systems is to code them using well-supported languages and frameworks.
Many LC/NC tools are new, immature, and come with significant technical limitations. These limits are usually not advertised and often also only sparsely documented. The only way software houses can really find these limits is to try a tool out and build a real application. Most limitations will only become apparent after a significant investment of time and effort. Software development is expensive and risky as it is and these unknowns increase the risk for developers, software houses, and their clients even further.
Lock-ins seal the deal
Many platforms don’t allow for applications built in that platform to be exported to generic, editable formats. They lock applications in, thereby either tying the developer to the platform or requiring them to rebuild their application from scratch. Considering that future requirements are uncertain and that limitations of LC/NC tools often remain hidden until late in the project, it is not surprising that developers can be extremely wary of getting locked in.
LC/NC has failed many times in the past
Visual development tools are not new. Early attempts at developing visually were already made 50 years ago. Since then a plethora of good and bad visual development environments and platforms have come and gone and none of them have made a significant difference to the way applications are created.
Anyone who bet on any of these tools, invested time and energy into learning them, and convinced clients to build their projects in any of them lost that bet. This history suggests that it is unlikely that any of the tools we come across today will still be around a decade from now. Many developers may consider these facts carefully and decide that LC/NC is a dead end.
Now what?
So, is LC/NC a lost cause, and is there no place for LC/NC in the world of serious software development? Can LC/NC tool makers somehow overcome these barriers and motivate more developers to use LC/NC products?
Many developers prefer code because of a lack of trust in LC/NC tools and the marketing communication that advertises them. To convince any professional to use a LC/NC platform, the platform makers require developers to trust them. To build this trust, toolmakers would do well to listen to concerns developers and software houses put forward and take them into account when planning platform features and when communicating with target groups.
The honest and truthful disclosure of functional limitations, the publication of ways to overcome limitations, flattening the learning curve for platforms, and allowing for the export of applications to editable formats are, while they may not convince all developers, steps in the right direction.