Does Low Code Mean More Work or More Freedom for Developers? – InApps Technology 2022

Low-code and no-code platforms aren’t going to steal software engineer jobs. Anyone who tells you otherwise neither understands a) what low-code and no-code platforms actually do or b) what software engineers actually do.

But low-code and no-code platforms are still likely to have an impact on the way engineers work or the type of work they do. It’s just unclear, at the moment, what the nature and extent of this impact will be.

We could look back in time as a guide to what we might expect from the low-code movement. If we do, the impact seems negligible, if not outright positive.

Excel — typically offered up as an example of one of the first low-code platforms — has arguably only precipitated the demand for software development skills, helping to embed and normalize digital technologies in everyone’s working life.

Similarly, more recent tools like Tableau have been valuable in lowering the barrier to entry to analytics. In doing so, it could be said that such tools have helped give many organizations the confidence to expand their digital capabilities.

However, it’s worth acknowledging that these tools weren’t described as no code/low code when first released to the market. With a broad, marketable term now at work across the industry, it’s understandable that there’s some skepticism. Such terms have a habit of obscuring — from a technical perspective — exactly what’s happening.

“A lot of low-code tools are being promoted with this kind of naive starting point that code is somehow bad, and that rankles a lot with programmers,” Mike Mason, global head of technology at the tech consultancy Thoughtworks, told InApps Technology in an email.

Indeed, read in a certain way, the term “low code” has echoes of “fat-free” — cheerily presenting itself as something simple and good for you while diverting your attention from the trade-offs that went into making it.

The Challenge of ‘Leaky Abstractions’

The skepticism about low code among developers isn’t just about how it’s presented, but also about how such tools actually work.

Back in 2002, Joel Spolsky — co-founder of HASH, Stack Overflow, Glitch and Trello — wrote about what he called “leaky abstractions.”

“One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to,” Spolsky wrote. This sentiment is an important one and pertinent in the context of no code and low code.

These products are, after all, layers of abstraction. While they may contain a promise of speed or simplicity, code, as Mason put it, “doesn’t magically go away just because you’re configuring it via point-and-click or some other mechanism.”

Dave Voorhis, a software engineer at the British tech consultancy BJSS, echoed some of Mason’s thoughts. “The impulse to create no/low-code systems is partly naive optimism — perhaps based on the assumption that text-based syntax is the problem, so text-free interaction will make it easier,” he said.

Voorhis qualified this, though, by highlighting that low code and no code “works well in niche areas” that “don’t require general-purpose programming.” In other words, these tools can be effective in areas that can be well-defined and delineated. This makes it easier to develop abstractions where the “leaks” are minor and easy to control.

Could Low Code Create More Work for Engineers?

In Ruth Cowan’s 1983 book “More Work for Mother,” the historian argued that the introduction of domestic technologies — like the washing machine — didn’t reduce the amount of housework done by women (as had been promised). Instead, such gadgets added to homemakers’ workloads.

It’s useful to consider this in the context of low code and no code. While it hasn’t really been remarked upon in wider coverage of these tools (typically, the framing is around the work that will be stolen, not created), it is, Mason suggested, a source of “a lot of the unease and skepticism” around the trend.

Part of this is due to the inflexibility that is an inevitable part of abstraction. “When you want to do something the low-code platform doesn’t support, you’re either fighting it or dropping down to normal code anyhow,” Mason said.

This means the “citizen developer” — a term that has emerged to describe non-technical people able to build applications — has to rely on the engineer to customize the tool in a way that fulfills their needs.

Anyone that’s worked with an “out of the box” CMS or commerce platform will know that “out of the box” rarely means exactly that. There’s a possibility that the current wave of low code and no code tools will be similar.

The Importance of IT Alignment

There’s also another potential risk: low-code and no-code platforms could create unwieldy legacy systems. Mason imagines a possible situation inside some organizations where “engineers don’t hear about the problems until the low-code system has grown into a giant hairball and is the next legacy system that needs replacing.”

In other words, if deployed in ways without oversight and direction, low-code and no-code platforms could increase “shadow IT.”

The way to tackle this is to ensure proper alignment between IT and other parts of the organization that may use a low-code/no-code tool. This is something Erik Lundegaard Hannisdal, head of sales for the low-code platform Genus, noted in a post on the company’s blog:

Are low-code platforms contributing to shadow IT? No, quite the opposite — a low-code platform sanctioned by central IT can be essential to mitigate shadow IT. The important premise is that the low-code platform must be governed and supported by the central IT department.

It’s interesting to see this in corporate content. Clearly, this is an issue that proponents of low code and no code have thought about.

Mason echoed this point: “I think the strategy should be to treat a low-code platform as a technical tool where traditional IT helps choose the platform, guides its use, educates developers and users, makes sure it fits into enterprise architecture plans, has a retirement strategy — all those things that ‘real’ systems need to have.”

Security and Low Code

This alignment is also important in the context of security. At a time when supply chain vulnerabilities are top of the agenda, it will be vital to ensure oversight of the low-code/no-code tools you bring into an organization.

“Attacks against development infrastructure — as we saw with SolarWinds — can be devastating,” Mason said. “These concerns don’t go away with a low-code platform, so it’s important to include them as an evaluation criteria.  “What is the vendor’s security posture? How do they secure the software supply chain which includes both their platform and your use of it?”

For Mason, while low code might look novel, the approach to security will be similar to industry changes over the last 10 years. “These questions are similar to ones you might ask about their cloud native architecture, or the way they handle horizontal scaling.”

Skepticism is understandable and might even be healthy where low-code and no-code platforms are concerned. Clearly, these tools could create issues for software engineering — and indeed, IT in general — if not used intelligently.

However, skepticism shouldn’t obscure the range of ways that low code and no code can help engineers and even allow them to focus on the work they want to focus on. Infrastructure automation, after all, still requires a degree of care and attention, but done well, it has also meant developers can focus on “hard” problems — which are typically the most interesting, too.

Greater Freedom for Engineers

This notion of freeing developers to tackle more creative tasks is something Emmanuel Straschkov, CEO of Bubble, a popular low-code platform, suggested to InApps Technology.

Low code “is definitely going to make the work of engineers more interesting,” he said. “They’re going to stop spending time redoing the same thing again and again and again.”

Straschkov is optimistic about the potential of low code, predicting that engineers will start focusing on more sophisticated work, “more algorithms that create value with code.”

He gives an example: “Lyft and Uber for instance — two amazing companies that basically do the same thing —or Deliveroo and Doordash. These companies have thousands of engineers doing exactly the same thing, and this is a really big waste for the world because we don’t need to duplicate that work. One team will be enough.”

While it’s not hard to appreciate Straschkov’s vision of letting engineers “focus on new things,” the reality is that this “waste” is symptomatic of commercial dynamics, not technical ones — the companies he compares to each other are business competitors.

But this then raises another question: could low code/no code shape future disruptions in the market? If the foundations of a given app are available “off the shelf” (to put it crudely), then it’s possible that organizations will be better placed to pay greater attention to the ways they differentiate their products and extend their value. That will have serious implications for how we think about the software and digital markets.

That remains to be seen; these big commercial changes are questions for another article. To focus on our immediate future we need to recognize that low-code and no-code platforms are likely to be most impactful when they’re viewed as an extension of our existing toolchains and ways of working, not a wholesale replacement.

How Can Engineers Use Low-Code Tools?

When thinking about the impact of low-code and no-code tools on engineers, it’s clear that a lot rests on the role of IT in managing their deployment and use. But there’s a whole other aspect too: rather than threatening developers’ jobs, making more work for them, or simply giving them something else to do, consider that low code and no code isn’t a threat but just another part of the developer toolkit.

In the hands of engineers, low-code and no-code tools could enable greater alignment between technical and non-technical teams.

Matthew Willox, a software engineer and owner of the metaverse blockchain company Cybermancers, told InApps Technology how no-code tools helped to transform a software engineering company (which he was hired into as a director) that was hampered by poor communication and understanding between developers and sales staff.

“I needed sales to understand what developers were doing,” he recalled. “So we went with no-code tools,” specifically Webflow and Unbounce.

“Our first project took three days to build from the first pixel to deployment. It was a small site, only four pages with a hero animation done with Lottie.”

Using the tools was incredibly powerful, Willox said: “I was able to educate salespeople. I had them follow along as we built it, and that gave them an intuitive sense of the work.”

This is an example of low-code and no-code platforms being used most effectively. As Mason said, “We have to remember where low code is coming from: there is an acute need for software in the world, and in general it takes too long to build and is too costly to support and evolve.”

Willox is familiar with this particular pain point. “I try not to fear things or form opinions without giving something a solid try,” he said.

However, what made Willox’s use of low-code and no-code tools effective can’t be explained by simple enthusiasm. It was more specifically his attentiveness to the nature of the problem.

This is another way of thinking about Voorhis’ point about low code being suitable for specific niches: as all-purpose tools, they have vague potential. But when used in a specific domain to tackle a particular challenge, that’s when they are really effective.

If low-code and no-code platforms are to have an impact on engineers, they won’t upend existing ways of working. Instead, they’re more likely to reshape it in the way that trends like containerization and cloud have in recent years.

However, a mixture of vigilance and curiosity will be important. Code will always matter; new seemingly intractable problems will always emerge. To solve them we need to recognize there’s always hard work to be done. We can’t pretend that there’s one simple trick that can replace the need for effort and thought.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Bubble.