9 dark secrets of low-code software development

The “low code” sales pitch is seductive. After all, who wants to spec out a months-long software project to be handled by a large team of expensive, opinionated developers when just a few or even a business user will do?

The low-code movement that has been emerging, thanks to tools that offer intuitive interfaces for building software, is enabling developers to snap together applications with a few clicks and, at most, a few hundred keystrokes.

But with ease comes complications. Lurking behind these programming crutches and mind-reading interfaces are several dark secrets that take a little shine off the seductive promise of low-code development.

Vendor lock-in

As with many technologies, the amount of work you do with low-code tools is proportional to the control you have. By handing off much of the work to the tools, the more you rely on them, and the more control they have over your process. Over time, what once felt like a “partnership” becomes a (potentially unhealthy) co-dependent relationship with their stack.

There are strategies for minimizing the lock-in that comes with using low-code tools. You can write your code to be more portable, isolating your business logic and then wrapping it with glue code that connects it with the local low-code API. Porting it to a new service is not impossible if you do a good job planning ahead. But notice how you’ll still be moving to another service. If you want to bring everything into your own servers, well, you’re going to have write the rest of the code eventually yourself.

Price control

Like many businesses, cloud platforms will often offer low prices to lure you in and then raise prices when they can. Thanks in part to lock-in, once you build your system on their platforms, they control the prices. Unless you sign a long-term contract, there’s no way to be certain what it will cost to run your product next year or five years from now, but if your low-code creation requires their back end, you can be sure they’ll remember this at the bargaining table.

The trickiest examples of pricing include shifting the formula. A service that once charged by the invocation may switch to charging by bandwidth. Or maybe they’ll offer some hybrid. The bean counters can run spreadsheets all day long, but you’re still probably going to just go along with the price change because it’s too much work to modify everything.

Blackbox

Most low-coders pay little attention to what’s going on behind the curtain. The platforms are attractive because they free us from that worry. But sometimes you’ll want to know, and there’s a good chance you won’t be able to find out. Maybe the code behind the curtain is officially proprietary. Maybe there are real secrets buried behind that API call, the kind that must be protected at all costs. Or maybe no one wants to answer your question because no one has made a decision and the lawyers gum up the works. Maybe their team finds you annoying.

This is especially tricky when regulators are involved. Banks, for instance, face questions about how they choose when to grant loans. An artificial intelligence service built into a low-code platform may be very savvy, but good luck telling regulators you have no clue what’s going on inside.

Inefficiencies hide in the cracks

It’s nice to hand over control to full-featured APIs, libraries and stacks, but often the code behind the curtain is much less efficient because it must be ready for many eventualities. Did some fool pass a null pointer? Are all the arguments for the function correctly formatted? These details can be checked again and again as your invocation works through all of the layers of the code. Low-code tools vendors must bullet-proof their wares because they don’t know what some fool might do. All that bulletproofing may be wonderful technically, but just like an armored tank, it’s generally much, much slower.

Limited capabilities

The demonstration is usually awesome. The charming sales engineer creates a new, cute doggy dating site in just one line of code by invoking the createDoggyDatingSite function that just happened to be built into the framework.

Most low-code platforms are a little bit more general, but the odds are that you’re going to quickly exhaust the powers of the built-in functions. Maybe you want your site to handle dogs and cats while keeping them from mixing. Maybe it’s an asymmetric relationship, say cats and gold fish, and the data structures need to keep their needs straight. The details are important to you and that’s why you’re building your app, but there’s no way that any low-code company could anticipate all of them.

Software can be flexible and adaptive to our needs, but we need to be in the loop. That is, we need to write the code that adapts it. The more flexibility we want, the more code we need to use to specify it. More code is not low code.

Monoculture

Some of the scariest bugs are the ones that we find in the most popular libraries. When someone found a problem with libssh, almost every Unix or Linux box in the server farm was at risk.

Successful low-code platforms create a monoculture by design and the monoculture is wonderful until a problem appears and then everyone has the same problem. The network effects that the venture capitalists chase are not just for getting people rich. Sometimes everything falls apart together when a fatal flaw is found in the network.

There’s no way to avoid this problem. The good news is that everyone has more of an incentive to fix the problems if we’re all in the same boat.

Homogeneity

A few years ago, a clever car lover noticed that it wasn’t so hard to build a car by calling up the car parts manufacturers, ordering their stock items and bolting them together. He spent most of his money creating a beautiful, curvy profile for the body but everything else was stock.

Other car lovers noticed. Isn’t that the door handle from a Volkswagon? Aren’t the seats the same ones in a Porsche 911? Isn’t the steering wheel a leftover design from Ford? Low-code projects end up generating the same effect. They end up feeling pretty similar to each other because the developers are working from the same bins of stock parts.

If the code is just there to do a job, say maintaining an inventory in a warehouse, the look doesn’t matter. But if the software is part of your brand, well, your low-code software is going to feel pretty similar to your competitors’.

Paralysis

Working with a powerful low-code platform is like playing in a garden. Everything is beautiful and simple — until you try to leave. The woods outside the garden are filled with darkness, uncertainty and doubt — and lots of work. If there’s a built-in function for what you need, the frameworks are great but as soon as you want to do something different paralysis sets in.

Low-code vendors like to tout their tools’ openness. You can link in any code. But just because you can doesn’t mean it’s easy. Often the startup cost of figuring out the interface can be ten times more complicated than the simple feature you want to add. Spending hours, weeks or even months trying to learn how to extend your project is frustrating, but it’s an accurate reflection of the investment you need to make in a platform. It’s not that stepping out of the garden is so hard; it’s that everything is artificially easy inside the garden.

Copy cats

If it’s easy for you to create it, it’s easy for someone else to copy it. Low-code platforms tend to avoid exclusive relationships. If the software is going to support another business with its own competitive advantages, well, that’s okay. But if creating the software is your business model, be ready for some competition.