The suits love the idea of “low code” tools. To them, less code means less work and less work means speedier projects, faster satisfaction, leaner budgets, and, ultimately, a fuller bowl of gravy for doling out big bonuses to those same suits. Who doesn’t like any of these things?
Developers for one. Oh, they like these grand promises in theory (who doesn’t want to do less work?) but they know there’s often a big gap between the theory of easier development and the reality that sets in when the deadline gets close and the tools don’t do exactly what they’re told.
Low-code solutions have a place. Programmers appreciate their ability to deliver something that works in less time with less effort. They know that low-code tools can produce a decent mechanism that can search, sort, and otherwise juggle tabular data. They’re happy to use them when the time is right.
But developers also fear getting stuck in corners, fiddling with all of the edge conditions, working around all the places where the tool doesn’t do the right thing automatically. They need to handle the glitches, fiddle with undocumented features, and figure out how to satisfy the requests to do things just a bit differently.
Developers get trapped between the promise of the sales pitch and the reality that working with low-code tools is often slower and more aggravating than writing your own stack—in other words, the high-code approach.
Here are 9 reasons programmers grow frustrated with the low-code tools that are supposed to save them so much time.
Low-code frustration #1: Maintenance can be hard
The trickiest part of dealing with a low-code solution is usually a few years down the road. The old system is deployed and running along smoothly, but everyone has requests for fixes and improvements. Many times, these extra features lie just outside the architectural structure of the old, low-code solution and there’s no easy way to add them. If we had the source code, we might be able to dive in and rebuild some of the guts, but we don’t. If the original designers knew the feature would be needed, they would have made different decisions. They might have started with a completely different framework. But they didn’t and now we’re locked in.
Low-code frustration #2: Everyone gets the same thing
Everyone who eats at a chain restaurant knows the boredom and lack of surprise. The business model depends on saving money on a standard menu and standard design while also providing a consistent experience, but that doesn’t make it more fun.
Low-code tools offer the same cookie-cutter feel. A good developer with just a bit of experience can often identify the underlying tools with just a few clicks. No matter how many configuration options, splash screens, or customized CSS skins, the underlying mechanism shows through. This can be comforting for some users who want things exactly the same, but it also removes much of the surprise and novelty.
Low-code frustration #3: One size fits none
The product manufacturers love items that are “one size fits all” because the pipeline is so much simpler. The customers? They often hate them and grouse that “one size fits none.”
Low-code products are easy to use in the same way. There just aren’t that many things for you to change, customize, or code and so you’re stuck with them. They do what they can do and that’s about it. No one ends up happy.
Low-code frustration #4: Sometimes coding is easier than configuration
Developers have been making a strategic mistake by minimizing the work that goes into configuring software. Maybe it’s because the bean counters compute metrics like the cost of each line of code. Maybe it’s because the suits are always comparing the cost of creating new code with the price of buying an off-the-shelf product. In any case, coders like to pretend that changing the parameters in the configuration files for a platform or tool is no big deal.
Low-code options tend to push the same story: You’re not coding when you’re specifying the algorithms, connecting the database, and filling in the parameters. That’s just configuration fluff and everyone knows that configuration is easy enough to do from your smartphone in a loud bar. But the reality is that those keystrokes might take days or weeks of fiddling until they actually do what they’re supposed to do. The vendors don’t want us to consider it “work” even if it takes longer than actually doing the hard “work” of writing code.
Low-code frustration #5: Too often low-code means flying blind
Over the years, developers have created elaborate debugging tools that make it easy to stop the software at arbitrary places and peer deeply into all of the data structures and algorithmic state to see just what is happening. Low-code tools hide all of this from us on purpose and think they’re doing us a favor.
If the low-code parts work as we expect, everything is sunshine and unicorns. But more often than not, something goes slightly awry and we’re stuck without any way to figure out what’s going on inside the black box. We’re flying blind without instruments and looking for any way to get some insight into what’s happening.
Low-code frustration #6: Sometimes you just need to insert a function to clean up the data
Anyone who has written software knows that half of the work is writing the extra little glue code that keeps the data flowing while filtering out the problems. Sometimes the dates are in ISO 8601 format and sometimes they’re in some local preference. Sometimes numbers are integers when they should be strings or vice versa.
Low-code products try to shoulder some of this work by offering filters or switches and these are often enough. But when they aren’t you’re out of luck. The low-code products are in a quandary. Some have experimented with letting you insert arbitrary blocks of code in places, but someone finds a way to misuse them and introduces a massive security hole. For instance, Drupal removed the option of including bits of PHP in places, to close a potential security hole and also increase cache performance.
Low-code frustration #7: Low-code is often inefficient
The promise of low-code tools is that they know what you need and then magically deliver it. The cost of this mind reading, though, is a thick stack of code that deals with all of the strange configurations and odd curveballs that might come its way.
If you wrote the code, you might know that your company only stored its data in CSV files. The team back at low-code headquarters, however, needs to plan for all of the contingencies and that means working with JSON, YAML, and XML, both versions 1.0 and 1.1. There are dozens of formats out there and the low-code sales team wants to make sure that their tool can handle all of them. It’s all about the check marks in the feature matrix.
The result is an impressive piece of engineering, just as impressive as the bulletproof Dreadnought, and it maneuvers with all of the grace and agility of the World War I battleship.
The result is that everything is slower and less efficient. If your deadlines aren’t too tight and your data set isn’t too large, you can hide this by throwing more compute power at the stack. But eventually the bill for the extra-careful code is going to come due.
Low-code frustration #8: Experience wanted
Many of the top open source platforms are built in popular languages that are taught in schools. There is a vast ecosystem of talent that can take apart and rebuild stacks built in the major languages like Java, JavaScript, Python, or PHP.
Low-code usually isn’t taught because, well, you’re not supposed to need any instruction in it. The devotees will point out that the tools are often written in common languages, but that’s not the real challenge for developers. The challenge is the extra structure bundled into the low-code framework. It’s what you’re paying for and it’s also what your team needs to spend time learning if they’re going to revise or extend the platform.
Low-code frustration #9: You’re locked in
Sometimes starting up one of these low-code platforms feels like joining the mob. It’s easy to join but hard to leave. The price for doing less work and standing on the shoulders of giants is that you become beholden to the giants. If the giants move, you move with them. If the giants stop moving, or collapse, you’re in trouble.