In a world with high stress deadlines and high maintenance bosses, the promise of low-code development tools sound great: With a few clicks, non-coders can stand up a simple app in a snap.
That’s the sales pitch from a wide range of vendors that have latched on to the “low code” buzzword. The marketplace is filling up with a large number of tools that can juggle all the bits with a minimum amount of babysitting. It’s more possible than ever to produce quality software without acres of cubicles and multiple warring factions of know-it-all developers.
Promises, though, are easy to make and harder to keep. Many savvy CIOs have heard the promises before and seen them fail at times. The history of computers is pretty much a history of programmers adding more layers of code to fix the rough edges of the previous layer. The first software compiler was considered a low-code alternative to writing machine code. Heck, machine code was a low-code alternative to rewiring the connections between the tubes. New tools have been promoted as a low-code enhancement to whatever came before.
The good news is that when viewed from a high altitude, the progression of tools has been wildly positive. We really can do much more with much less work. The news from the trenches, though, is often more confusing. Often a big improvement comes with the responsibility to manage it. Sometimes it can be almost as much work to master a tool and find the best way to configure it as it can be to build something from scratch.
Understanding and managing this tension is the biggest challenge for companies considering low-code options. Will the obvious advantages they offer be worth the costs that might be waiting a few months down the road? Deciding how much to embrace the current round of promises requires a careful balancing of these seven reasons to embrace low-code tools and seven reasons to avoid them.
Low-code vendors have one goal in mind: helping everyone create new software quickly. With a few clicks, users can create a page with a form. String a few forms and views together, and you’ve got an app. The click, compile and test loop is often fast enough that some agile users can develop apps in real time during the meeting in which the app is being discussed. The good news is that the tools often do exactly what they promise. If your needs hit the sweet spot of what they can deliver, you can be finished in less time than it takes to get a team of real developers to jump on a video call.
Slow down a bit. It’s nice that the tools are fast, but it can be a mistake to rush software development. As coding becomes easier, the real challenge is defining the application and imagining its role in the lives of the customers.
Focusing too much on speed can lead to disappointment when the work isn’t done in a few minutes. Yes, the team may have clicked together three prototypes in that time, but along the way they ignored ten conceptual roadblocks and dozens of philosophical wrinkles that must be smoothed out. Clicking can get in the way of strategic thinking. The real challenge isn’t creating what you want, it’s knowing what you want in the first place.
Custom software is hard for companies to maintain. Creating the tool is just the beginning of a support process that lasts as long as the software serves the company. Often just keeping the screws tightened and the chrome polished is more work than building the original version.
Low-code tools amortize the support costs across all the installations. When a new version of the OS comes along or some new data storage regulation passes Congress, low-code tool vendors will implement it for everyone. Adopting a low-code platform is more than joining a club; it’s marrying into a dynasty. It might be a small dynasty, but everyone’s interests are aligned, and this can bring greater stability than if you tried to manage it with your own employees.
Con: Shared fate
Offloading support to the company that built the low-code platform can save lots of money and time, but stability isn’t guaranteed. Sure, some well-managed frameworks sail into the future carrying everyone along, but not all businesses are well-managed. Any number of corporate mishaps could scuttle your platform. Maybe the CEO has a midlife crisis and wants to get into gaming. Maybe the CFO played fast and loose with the IRS. Maybe the rock-solid genius who built the platform heads off into the woods in search of enlightenment. Any problem can undermine the stability of your low-code tool. You’re putting your faith in another organization and your only lever of control may be the yearly contract renewal process.
A good low-code platform doesn’t just help the IT department, it can unleash the creative genius of business line employees, those with big dreams but not enough budget to fund a real development team. Now they can spend a few hours clicking to try out an idea instead of drafting endless spec documents and budget requests.
Low-code features can be miraculous, but they can’t turn a non-coder into a senior-level developer, even if the non-coder can click with just as much clicking talent as the best undergraduate at MIT. Users still need to have a basic feel for how computers work and juggle bits. A spreadsheet master, for instance, should have little trouble using these tools, but someone who shrieks with fear at changing the margins on a word processor won’t magically be able to churn out three apps before lunch. The tools handle many of the chores but they can’t escape the fundamental philosophical limits of computation and the current computing environment.
The world runs better because we have evolved some standard solutions. All cars have the gas and brake pedals in pretty much the same location. Refrigerators tend to store the butter in the same location. The great thing about churning out an application with a low-code solution is you’re probably going to build on a widely used collection of user interface widgets. Your code will be relatively standard without even trying because your code will be using the same tools as others.
Doing everything the same way as your competitors may make it easier to hire away staff but it also dooms you to getting lost in the crowd. Some software packages are meant to attract attention and distinguish your enterprise. Doing everything the same as everyone else ensures you’ll be indistinguishable.
Low-code platforms are usually engineered to handle the most common challenges such as safety or data privacy. If there’s a law in Europe or some security nightmare attacking Asian companies, there’s a good chance that the low-code developers have already addressed it. That’s the big advantage of working with a shared framework. They’ve handled the common challenges so you don’t need to worry about them.
Con: Socialized Costs
Low-code platforms are shared resources and that brings disadvantages as well. Maybe your application is filled with social media postings that people desperately want to be broadcast far and wide. Yet the platform developers have engineered their tool with rigorous privacy protections for health records. You’ll be paying for these costs — and maybe even pulling out a bit of hair every time the restrictions get in your way.
Low-code tools are designed to be simpler. While you’re worrying about your business, low-code platform developers have been fretting over the best way to build a set of tools that are easy to adopt and extend. That’s their business. It’s dangerous to believe the hype and imagine that it’s all going to be as simple as daydreaming of outrageous fortune, but it’s going to be simpler than getting out the programming books and starting from scratch.
Can low code be more confusing than writing something from scratch? Yes! It tends to happen when you push the limits of the tool and start bumping into glitches, bugs or inconsistencies. This is only natural, and all software has these issues. The difference is that the low-code tools never wanted to expose this side to you. It’s like they’re selling a car with the hood welded shut. The data structures and algorithms are opaque so you don’t worry your little head. But if suddenly something doesn’t work and the only way to recognize what is going on is to dig into the data structures, well, confusion emerges. Those details aren’t for you — and sometimes that leaves you more lost than if you did the hard work yourself from the beginning.
Pro: Plays well with others
At the core, the decision is one of philosophy. Some companies encourage developing a web of trusted partners who contribute experience and stability. They believe that the company does not live alone, but thrives as part of a network. Embracing a low-code tool kit adds another connection to the network of trust.
The opposite approach is to develop in-house expertise because this depth of knowledge pays off. They know that low code may deliver a jolt like three or four cups of espresso, but in the end everyone ends up a bit dazed and out-of-touch with what is going on. Only solid, well-structured code built by a dedicated team builds something of long-term value and that’s why CIOs hire good teams.
The lowdown on low code
Some savvy IT managers will make different choices for different jobs. Casual explorations, pre-alpha prototypes and backend processes that run occasionally are good candidates for low-code tool sets. The team can spin something up quickly and nothing will be lost if it stumbles or even falls.
But if the code is going to maintain the core workflows of the company and contribute directly to the bottom line, you’re not likely to want to rely on some brave intern fiddling with a fancy spreadsheet. You’re going to invest in the talent needed to create something trustworthy.