What the Low-Code Boom Means For Developers

Lines of code on a black screen

You’ve seen the articles and heard the hype — the “low-code boom” is upon us. From app development tools to SaaS website services like Wix to Acquia’s own Site Studio tool, it seems that you can’t go one day without hearing about the popularity of the low-code movement. But, what does low-code mean for developers? Are our days numbered? Will the rise of the “citizen developer” and AI lead to the death of the developer role?

In short, no. The low-code boom is a disruptive force in our industry, but it’s also not the first time we developers have experienced disruption. Our ability to adapt to the continued evolution of technology means that we are more valuable than ever before.

Our mission with regard to the low-code boom is actually quite simple: we are the trusted technical leaders perfectly suited to guide organizations through this disruption.

What is the low-code boom?

There are many different definitions of “low-code”, especially depending on what people are trying to sell. In general, though, low-code tools provide a GUI for doing work that reduces the required amount of hand coding. A major benefit of low-code tools is that they increase the number of people that can contribute to the development process, including those who don’t know how to write code.

According to Gartner, the global market for low-code development tools will hit about $14 billion this year, almost 25% higher than last year. About 40% of employees outside IT build or customize data solutions, and half of the new low-code customers will come from business buyers outside IT before 2026.

On the surface, this might sound like a threat to developers, but that changes as you look more closely. Many low-code platforms are either aimed at developers or otherwise require technical knowledge to work efficiently. Low-code tools can accelerate projects, but without governance and direction, they also accelerate the creation of bugs and technical debt.

Only systems architects and developers have the experience and deep technical knowledge to properly evaluate these tools, utilize them, and integrate them into the increasingly complex technical stack that is required to do business today.

Do you even code?

The history of software development is the story of making technology more accessible and easier to use. We no longer program by flipping switches or using punch cards. The goal is always to build faster with fewer bugs and greater reliability. Low-code tools are a means to this end.

Much of the resistance that I see to low-code tools comes down to fear and pride. There is the ever present fear of being replaced, outsourced, or otherwise “devalued” as a resource on the team. That risk does exist, but it can be turned in our favor.

The other source of resistance, pride, is nothing new to developers. There are constant arguments about the “best” programming languages, or even what a “real programmer” is. There are myriad opinions about frameworks, tabs vs. spaces, architectures, RISC vs. CISC, and more… often with a heaping spoonful of judgement.

I am personally a huge fan of PHP and JS, with Drupal as a framework, and I have been on the receiving end of plenty of pointed discussions about those not being “real” tools. At the same time, I’ve also suggested that Drupal is the original low-code framework. I know from experience that a solid low-code framework is an incredible accelerator that has helped many developers advance faster.

Both fear and pride are normal human emotions, and this response to disruption is understandable. However, our value comes from our technical prowess and understanding. We can’t stop the low-code train, but we can, and should, help guide the tracks.

Low-code makes you more valuable

Ultimately, this is about the value of a programmer or developer. The low-code boom will remove some of the technological difficulties that make a developer necessary, but that doesn’t impact our true value.

Technology is the foundation of every modern business, and everyone knows how vital it is. Even though more people care about technology, they don’t necessarily understand its depths. The greater the access to technology, the more that developers are seen as experts. The low-code boom gives people powerful tools that reinforce the need for developers to guide, integrate, extend, and enhance those tools.

As developers, we want to leverage low-code tools to increase the amount of high value work that we can do. This is not only better for the organization, but it is better for us. We increase our skills; we learn new things and the perception of our contribution is higher than ever.

When they are used properly, low-code tools will free us from low value (boring) work in order to refocus on high value (interesting) work. This high value work requires skilled developers and empowers us to promote more challenging, interesting, and useful projects that wouldn’t otherwise be possible.

Communicating your value

Consider the humble spreadsheet. Excel has enabled the business user to create calculation tools and programs without needing a developer, and has even been proven to be Turing complete . More people know how to “program” in Excel than in any other language, but has it been a threat for developers? No! In fact, the opposite — it has freed the developer from lower value tasks, so they can work on much more interesting, fun, and high value projects.

Just as advances in AI and computer algorithms are helping marketers understand huge quantities of customer data, so they can prioritize campaigns with greater impact, the low-code movement cuts away the chaff of tedious IT requests, so developers can focus on bigger tasks. Low-code tools can reduce our support burden and help remove IT as the real (or perceived) bottleneck in business workflows. They streamline the common, everyday business tasks (like creating content) and provide more resources (time/money) for the developer to truly shine.

Developers are vital in ensuring that the entire tech stack is composable, performant, and secure. There are tons of process improvements that everyone knows they should do, but not everyone has the budget to invest in: CI/CD, automated testing, code audits, performance and security testing.

Most importantly, developers need to be free to innovate! This is the highest value activity that we can engage in. We can create true value that no other part of the organization can touch — like machine learning, better integrations, big data, real time responses, seamless user integrations, IoT, and even greater things that perhaps no one has thought of yet.

Once we start focusing on the innovation, enhancement, and platform based mindset, we see that there is endless opportunity for us to not only communicate our value to the business, but also increase our own experience and personal value through the process.

Embracing disruption as the future of digital progress

Low-code tools are not going away. Computing history is a steady march from changing gears and switches to punch cards to assembly language to compiled code to interpreted languages and now to low-code tools. The constant goal is to make it faster, easier, and safer to deliver ever more advanced solutions.

There is no denying that the boom in low-code tools is disruptive. However, developers have long been used to disruption! We are arguably the most comfortable and well positioned people who are able to deal with it.

Developers have the experience and vision to understand what those changes will be, and how to lead the business into the best position for the future. We can align ourselves with the disruption and actually increase our value, rather than see it diminish.

Low-code tools are only tools, at the end of the day. As developers, we are experts in learning and using technical tools to do cool stuff. We should ignore the fear and pride that might hold us back, and embrace our own curiosity, excitement, and experience. This is the source of our true value and that is ultimately what makes us invaluable.


This post was originally published on the Acquia blog