“In the last few weeks, I've been approached by two individuals representing two different companies introducing no-code software tools. Both are convinced they have the revolutionary replacement for those pesky code monkeys we call software engineers.” - A Chief Software Architect on LinkedIn
This is how on LinkedIn, a chief architect recounted his experience of sitting through two sales meetings with no code development vendors. He then went on to say that:
“The reality is that if you want a no-code solution, you are simply adopting someone else's code […] pretending to be your code.”
His post received more than 1000 reactions and was reposted more than 100 times. Clearly, “no-code” seems to hit a nerve with developers. Just not the right one. No Code? No, thank you.
Why is no code development such a hot potato for software developers? Let's explore.
What is No-Code Development?
No-code development is an approach to application development that relies on abstractions instead of code. They are highly opinionated application development platforms that prescribe a certain way of building and deploying applications.
In no-code development, applications are primarily developed in a visual drag-and-drop, or a What-You-See-Is-What-You-Get (WYSIWYG), interface. The use of high code is very limited, if not outright impossible, in no-code development.
The philosophy of no-code application builders is that code is the source of evil: code is what makes application development complex, cumbersome, error-prone, and time-consuming.
No code aspires to democratize application development and to break down the traditional distinction between application producers and application consumers. In no code, application builders and application users are one and the same.
Whereas in the past, when you needed an application, you'd bring your requirements to a trusted and trained software developer, no code holds that those in need of applications should be empowered to build them themselves.
No code development is especially popular in the start-up community, where time and money are of the essence and technical talent is rare. It is a technological representation of the age-old start-up mantra to "fail fast and fail cheaply".
No code development is a great approach to spin up a minimum viable product (MVP) quickly and at a low cost. Popular no-code application builders are Bubble, Appsheet (Google), AppGyver (SAP), and Knack. All offer quick and cheap application development for non-technical users. And big companies are taking note: Microsoft recently announced the inclusion of Bubble, a popular no-code development tool, in its start-up program.
Three Reasons Why Software Developers Reject No Code Development
Most software developers are skeptical about, if not outright hostile to the idea of no code development.
The idea to build applications entirely without code simply does not resonate with them. To them, no code is not a software development trend. It's a software development fad.
Does this come as a surprise to anyone in the industry? Not really.
1. Software Developers Are No Code Luddites
First, history is full of examples of workers opposing higher degrees of automation and abstraction.
Most famously, the Luddites, a group of English textile workers, opposed and destroyed machinery that was perceived as threatening their jobs. This is why nowadays, the term Luddite is used to describe anyone who opposes new technology or ways of working when this new technology is (oftentimes, mistakenly) perceived as taking away their livelihood.
How do software developers make a living? By writing code.
Software developers are most enthusiastic about the challenge of building complex web applications whilst maintaining a codebase that reflects their creativity, ingenuity, and elegance. No code development platforms, which are oftentimes pure drag-and-drop or What-You-See-Is-What-You-Get (WYSIWYG) take away their freedom to do what they enjoy most about their work.
2. Software Developers Have Abstraction Fatigue
Secondly, the idea to accelerate application development is not a new trend in software development. In the 1990s, this idea was referred to as rapid application development (RAD). But after an initial hype, these platforms never took off. To software developers that have been in the industry long enough, no code is old wine in new skins.
Some developers are so fed up with the idea of getting rid of code that they suffer from what I would call "abstraction fatigue". For example, here is what a developer wrote on an online forum in response to the idea of working with less code:
"I'm an actual developer and of course you're right: developers are swamped and can't meet deadlines [...]. However, it's not because there's too much custom code. To be very blunt, I'll tell you it's because there's not enough."
He goes on with an example:
"We needed to display live data with a few joins and transformations from a database, in a few grids. Well, it became a good opportunity to abstract this away so someone 5 years ago, we're not sure who decided to build a framework. We now have a wonderful grid builder that takes 200 lines of configurations when you want to add a new grid, after of course, you spent 3 weeks reverse engineering the framework to fix 3 missing features that you also needed."
3. No Code Development Doesn't Mean No Code
Last, most software developers oppose the idea of no code on the grounds that the word is a misnomer. No code does, in fact, not mean no code: instead, it just means that you are "adopting someone else's code pretending to be your code".
There is still code. After all, the very no code tool you are using is a piece of software. And all software consists of code, as code is the only way for a human to give instructions to a computer. You just cannot see it or touch it.
This is where software developers' rejection of no code is different from the Luddites' rejection of mechanized looms and knitting frames. A mechanized loom, or any piece of physical equipment, can usually be fixed when it's broken. A pure no-code platform, on the other hand, is a piece of software that can turn into a black box. Its codebase isn't easily accessible.
In addition, the “no” in "no code" can create a brick wall. No-code tools are highly opinionated platforms for application development.
Once you want to step out of the no-code solution and build something that the platform does not provide, you’ll hit that brick wall straight on. No-code tools are like a box of Legos. There’s a lot you can do with them, but you’re limited to what you find out of the box.
Given these reasons, it's not a surprise that software developers haven't jumped on the no-code bandwagon. Neither should they, however. No code development is not for software developers. It's primarily made for non-coders.
Non-coders, or citizen developers, are amazed by what they can build without writing code. Software developers, on the other hand, dislike the loss of control and flexibility from not being able to use code.
No Code Development in Enterprise Application Development
So far, we've primarily looked at software developers' general response to the idea of no code.
But what about no code for enterprise application development? Is no code development gaining traction inside companies? And how do CIOs, CTOs, and enterprise architects think about no code?
Microsoft's Power Apps, for example, is a popular no-code tool. Power Apps is used to build apps that allow business users and domain experts to take action on their data.
Power Apps is great for replacing paper forms, legacy solutions, or just that spreadsheet that departments and coworkers pass around. According to Microsoft, anyone who knows how to use Microsoft Excel or PowerPoint can build custom business applications with Power Apps.
What do software developers think about Power Apps?
In a podcast, Microsoft's Charles Lamanna, who's in charge of Power Apps, states that at Microsoft, more than 150,000 applications have been built using Power Apps. This number is impressive, but it also comes with risks.
One of the main risks of no-code development is shadow IT. The ease with which no code tools let citizen developers build applications can lead to a patchwork of untested applications that run without any centralized oversight.
Not surprisingly then, some IT decision-makers push back on the idea of no-code and citizen development. And for good reason: IT and data security usually fall into their area of responsibility. Managing thousands of applications that are custom-built by citizen developers is not a dream come true. Just on the opposite: it is the stuff of nightmares for those responsible for IT.
High-Level Languages & Abstractions: How Modern Software Gets Built
Software developers' objection, or rather rejection, of no-code development, is not 100% accurate, however.
"Reducing the amount of code by finding suitable abstractions is a worthwhile endeavor and something we have been doing for a long time, without any slogan", says Gregor Hohpe, author of "The Software Architect Elevator". And he is right.
Software development purists like to say that the only code you can trust is your own code. But long-term trends in software engineering show that today's software developer only produces 40% of newly written code as developers 40 years ago.
Code reuse has been on the rise for decades and is a long-term software development trend. It has been shaping the industry and the work of software developers since its earliest days.
Second-generation languages are higher levels of abstraction than first-generation languages or machine code. IDEs replaced punchcards. And third-generation, or general purposes languages, such as JavaScript, C#, or Rust, introduced yet a higher level of abstractions on second-generation languages, making programming a more human-language-like activity.
Nowadays, frameworks and libraries such as React, Angular, Ruby on Rails, or Laravel, are all designed to make it easier to build web applications that users will love with less code. And AI and GitHub's Co-Pilot even write and debug code for us.
In short: Programmers can, and always have done great things if they were not forced to constantly reinvent the tools that have already been built.
The Art of Releasing Good Software
The entire no-code development debate is oftentimes dominated by the question above: what is the role of custom code?
Is custom code still necessary? Is it a liability? Is "code the stuff that contains all the bugs"? Or is custom code our only safeguard against unmaintainable, black-box software?
However, software engineering is more than writing code. Developers are more than code monkeys.
Software engineering is a complex process that starts with gathering requirements and ends with handing over a working piece of software. Programming, or the act of writing code, is just one step in this process.
This is what many no-code companies get wrong - and what low-code platforms, which give developers access to a high-code interface, get right.
The real debate should be about the question of whether any given tool can accelerate software engineering, what features it would need to do so, and to what extent it is relying on proprietary ideas or established standards.
Accelerating Software Engineering: Look Beyond Programming
Let's start with the first point: accelerating the process of software engineering. Most no-code and low-code tools offer application development, as well as deployment features.
A simple test to understand how these platform vendors think about software engineering is by asking how exactly these tools handle deployment: what are you deploying to and how do you manage your releases and versions?
For example, some no-code tools do not provide testing or sandbox environments. They only have one environment per application. Any change made to an app is automatically pushed into production.
Building a new feature in a tool without multiple environments means rebuilding your application from scratch, testing it, and then migrating your users to the new app.
This invalidates the platform's use for building any kind of serious software application. Other features to look out for are debuggers, audit trails, security, or deployment, and indeed: can I use high code? Having access to a code editor is a must-have, especially if the platform promotes itself to software developers.
Choose Boring Technologies
A second question to ask is to what extent application development platforms rely on established technologies.
Some platforms in the no-code and low-code space use newly created, and sometimes proprietary languages. Microsoft, for example, has created its own language for the Power Apps platforms called Power FX. Zoho Creator, another platform, is also using a proprietary language called Deluge.
It'd be hard to come up with an accurate estimate of the number of developers fluent in Power FX or Deluge - but it is safe to say that the number will be significantly smaller than the number of developers who know how to read and write languages such as JavaScript, SQL or C#.
The disadvantage of choosing a platform using its own, newly-created language is obvious to experienced software developers: newly created, or proprietary languages, do not have large support communities, are not widely used, and are not as tried-and-tested as more established technologies, such as SQL or JavaScript. Online forums, such as StackOverflow, make it easy to find support quickly.
The same argument can be made for databases. Almost all application development platforms offer some kind of integrated database. These are sometimes proprietary databases or, alternatively, one of the usual heavyweights, such as MySQL or PostgreSQL. If data portability is a concern, then selecting a vendor that builds on top of a standard, relational database is definitely the way to go. Avoiding anything proprietary, custom-built, or unique means less lock-in and less dependence on the vendor
A wise software developer once summed this up by saying: "Choose Boring Technologies". Go with what's tried and tested, and has been around for years - especially in enterprise application development, where taking risks has few rewards.
Conclusion
No doubt, the no-code development trend is here to stay. It has its place in the start-up community.
But it's not here to stay with software developers and is more unlikely to have an impact on enterprise application development.
No-code tools are great for people who have never written code before. For most professional developers, however, adopting somebody else's code means risk and loss of flexibility. And rightfully so: a lot can be achieved with abstractions. But not everything can be built in drag-and-drop or WYSIWYG. In addition, software developers understand that software engineering is more than programming and that releasing good software quickly is not just a question of writing code or not.
No code development is a suitable approach for quickly and cheaply building a start-up MVP. But it is not suited for enterprise application development.