The promise of low-code development couldn’t be more seductive. Who doesn’t want to do less work? Who doesn’t want to lean back and let the darn machines pick up the slack? We’ve been telling them what to do for decades, after all. They should have figured out a thing or three by now.
The good news is that more and more companies have found ways to create packages that are worthy of the much-hyped phrase, low code. Some are so good they might really be ready for the even more hyped phrase, no code.
The reality is that software stacks have been transformed by a mixture of sophisticated dialog boxes, vastly improved drag-and-drop interfaces, more resilient databases, and better integrated development environments. Adding just a bit of what might be called artificial intelligence (AI) seals the deal.
We’ve all seen the sales demonstrations. After a few clicks, the stack is up and running. A few more clicks integrates it with the local LDAP, so that everyone in the office can log in to do their work. A few more clicks, and the system starts to pump out reports and spreadsheets. For the humans who are lucky enough to still be part of the workflow, it all looks like magic.
But even when the good demonstrations are done and the code is running smoothly, there are reasons to think twice. Behind the well-polished facade are issues that can’t be fixed by clicking on a simple dialog box.
Alas, for all the promises and even undeniable success stories from companies delivering low-code packages, there are reasons to be more than a bit wary. Some things are not as good as they seem. Here are six reasons to be cautious about drinking the low-code kool-aid.
Automation makes us stupid
The low-code sales pitch is that computers and automation make humans smarter by providing a computational lever that multiplies our intelligence. Perhaps. But you might also notice that, as people grow to trust in machines, we sometimes stop thinking for ourselves. If the algorithm says it’s the right thing to do, we'll just go along with it.
There are endless examples of the disaster that can ensue from such thoughtlessness. In 2016, airports were jammed and many flights delayed because a computer glitch left airport staff confused. Staff "didn’t know who had already gone through the [security] gate," according to one newspaper. In the past, we humans were still capable of taking over and, say, landing the plane in the East River in case of a systems failure. Once we start to over-rely on machines, particularly given the temptations of low-code, will we still be able to rally in an emergency?
Majority rules
Low-code solutions are designed to satisfy the majority. If your business is a bit different, well, the options for customization may not be enough. In the end, you too will start following the crowd, and your business will become more like the rest. Perhaps that won’t matter, but if your business relies on having its own special workflow, process, or approach, the only way to support that will be to write your own code.
Cruft accumulates
When humans write code, we naturally do the least amount of work required, which is surprisingly efficient. We're not cutting corners; we're just not implementing unnecessary features. Low code solutions don’t have that advantage. They are designed to be one-size-fits-all, which in computer code means libraries filled with endless if-then-else statements testing for every contingency in the network.
Low code is naturally less efficient because it’s always testing and retesting itself. This ability to adjust automatically is the magic that the sales team is selling, after all. But it’s also going to be that much less efficient than hand-tuned code written by someone who knows the business. Maybe this extra cruft isn’t so bad at first. Maybe the cloud company will give you lots of free credits. But eventually, as your project scales, someone is going to have to pay for all those extra if-then-else loops.
Bias in the machine
For all the awe-inspiring abilities of AI, no one really knows how much bias and inaccuracy is hiding in its models. Low-code platforms have the same problem.
This isn’t a new issue. The humans being replaced by low-code platforms have always had plenty of biases that affected the software they created. It’s just that we’ve been struggling with human biases for millennia now, and we’ve evolved many systems for fighting them successfully. We’re not perfect, but we understand some of our failings.
Low-code systems are new. We’re just starting to understand how they can make subtle and not-so-subtle mistakes. Once we get over our feelings of awe and stop automatically deferring to the magic algorithms, we might start to find a way to fight the bias that’s hidden inside.
Dubious improvements
How much of the work of software development is really about wrestling with semicolons and variable types? How much more of it is spent in meetings with stakeholders asking you to move the button a few pixels to the left and add a bit more red to the background color?
Some coding is mentally challenging, but a great deal of it is perfunctory. The real work is dealing with humans. Often, the low-code version of an application replaces a library procedure call with a dialog box for inputting the three RGB shades for the background color you want. Is typing those parameters into a box that much easier than writing out a line of Java, Python, or C++?
We like to imagine that low-code dialog boxes are saving us time, but in many cases, they just put a facade on the same mental workflow of design thinking. The fancy low-code interface might be more efficient than poring over documentation, looking for the right syntax for a procedure call. But it's often not as much of a timesaver as you might expect.
Hidden costs
When low code works well, everyone is happy just clicking away. But when it’s not running smoothly, only a real programmer can figure it out. Sometimes the problem is that you need to do something a bit non-standard that the low-code system wasn’t designed to handle. Sometimes, you’ve pushed the system so far that it’s glitching or crashing. In any case, only a real programmer who knows how to write real code can find a solution.
The problem with low code is that it often only solves simple problems like syntax. Everything under the surface still requires the skills of a good coder who can reason about all the hidden machinery we no longer see. Low-code systems are still software, and there’s no escaping the need for someone who speaks their language—that is, the language of bytes, arrays, and data structures.
History repeats itself
None of this is new. In 1841, when we were watching technology transform transportation, textiles, warfare, and almost every part of society, Ralph Waldo Emerson paused and wrote an essay called Self-Reliance.
“Society never advances,” he explained:
It recedes as fast on one side as it gains on the other. It undergoes continual changes; it is barbarous, it is civilized, it is christianized, it is rich, it is scientific; but this change is not amelioration. For every thing that is given, something is taken. Society acquires new arts, and loses old instincts.
The same holds for low code. This isn’t to say that we should throw it away or abandon the path. We never gave up on using technology for transportation or manufacturing; we just recognized that the available solutions weren't perfect. Technology presents hidden dangers, and many of them can only be solved by careful attention and copious amounts of human intelligence.