Why “low code” and “no code” platforms are like Japanese knotweed
There is nothing novel about "low code" and "no code" development. The idea of building applications without the need for engineers has been popping up in different guises for decades.
From the early 1980s onwards the idea of fourth generation languages, or 4GLs, became an umbrella term for attempting to provide a higher level of abstraction than "3GLs" such as Java or C++. This gave rise to a wide range of platforms, including UI development environments, code generators, reporting tools, and query languages.
These platforms pointed to a bright future where "citizen developers" could be empowered to build their own solutions with simple drag-and-drop tools. The reality turned out to be a little different as development tended to be undermined by unrealistic expectations, security concerns, and scalability challenges.
Forrester's "low code" wave
Most tools in this space were overrun by the Cambrain explosion of web application development that rolled in from the 1990s onwards. The phrase "low code" was first coined by Forrester in 2014 to describe an emerging ecosystem of SaaS-based vendors such as Salesforce and Appian. These vendors provided visual, drag-and-drop tooling that empowered a new generation of "citizen developers" to build process-driven applications on top of data models and workflows.
Now "low code" is giving way to the more ambitious promise of "no code". Even the main cloud vendors are getting in on the game with AWS Honeycode, Google AppSheets, and Microsoft PowerApps. It seems that "low code" and "no code" platforms are having a bit of a moment.
The idea is everywhere. Integration platforms let you build "code free" data pipelines with point-and-click "doodleware". Business rule engines promise to take rule-based logic out of the hands of engineers and into the hands of business analysts. Workflow engines offer to tie your processes together without any code wrangling. Websites, mobile apps and online stores can be built without having to learn any of that pesky code.
It is an alluring idea for business stakeholders, tired of having to engage with the arcane world of software engineering. It presents an opportunity to democratize technology and expand application development to a wider talent pool. Productivity can be increased while the overheads of building and maintaining applications can be reduced.
What's not to like?
Unintended consequences
You can build perfectly good applications with "low code" and "no code" platforms. They really can fill a sweet spot for technically-savvy business users who want to build simple web applications or automate straightforward processes.
However, these platforms all suffer from the same basic shortcoming: they may be a good fit for simple use cases, but they can make complex problems far more difficult to solve.
A simple use case rarely stays that way, especially if an initial implementation is successful. This can give rise to a more ambitious application, requiring capabilities that are not easily achievable in the platform. Over time, creeping complexity can lead to a sprawling mess that everybody is scared to change for fear of breaking something.
Many IT departments anoint "low code" platforms as a means of containing and harnessing the "shadow IT" that can build up among technically-savvy and highly motivated business users. These implementations tend to drift out of their planned context as internal advocates champion their use around the business. The "solution looking for a problem" approach to application design can cause a spread of unplanned provision that is hard to contain.
ThoughtWorks likened this behaviour to "Japanese Knotweed", and it is a great analogy. You think you can contain it, but it spreads silently out of sight to infect and undermine your foundations. Once established, it requires a determined programme of extermination to reliably rid yourself of it.
Can you really build applications without engineers?
At the heart of "low code" provision is a conceit that we will inevitably be able to eliminate engineers from application development, leaving delivery in the hands of an army of "citizen developers". This is hokum.
At the very least, these platforms require users with an engineering mindset who are prepared to negotiate a significant learning curve. If you need to extend the default functionality offered by the platform then you will still need to call in some engineers to write code.
The reality of working with both "low code" and "no code" tools is generally more aggravating than the smooth, accelerated delivery promised in the sales pitch. Much of the "development" involves fiddling around with edge cases or trying to work around those cases where the platform doesn't do the right thing automatically.
When it comes to more complex use cases, engineers will spend most of their time working out how to overcome the shortcomings of the platform or alter its default behaviour. This often involves pasting code into arcane areas of a "low code" interface where it will be hard to find again, let alone maintain. The overall effect can start to feel like "duct tape and chicken wire" engineering.
Longer term prospects...
And who maintains these applications over the long term? Pity the engineers who need to make sense of "low code" or "no code" applications a few years after they have been built. The applications will not follow anyn widely recognised conventions or design patterns that normally help engineers to navigate unfamiliar code bases. The platforms tend to be immature, lacking the knowledge resources and community support that engineers typically draw upon to solve problems.
Apart from being the mother and father of all vendor lock-ins, "low code" and "no code" applications can have a limited shelf life. Vendors can deprecate versions of their platforms or introduce breaking change that amounts to much the same thing. Once the vendor loses interest in actively supporting your application then you can find yourself scrambling to replace something that has no upgrade path or practical escape route.
The best recent example of this sudden obsolescence is Google's cancellation of its App Maker product, where they replaced it with the wholly incompatible AppSheet. That should be enough to chill the blood of any "low code" advocate…