The low-code concept has been gaining traction for the past couple of years. The promise of low-code is the removal or reduction in the amount of programming required when building applications, especially in-house applications for managing and processing data sets.
Instead of painstakingly crafting together new applications from scratch, developers—and perhaps even non-developers—can pull together a range of building blocks in a visual development environment. Then they just click a few buttons and—voilà!—a newly built application emerges.
It’s easy to see the appeal. Many organizations are struggling to create all the in-house applications they require to manage and mine their ever-growing sets of data. Low-code offers a ray of hope, a way of offloading the tedious grunt work of coding to APIs, applets, and services. It’s exciting because there’s a whiff of science fiction about it; drag blocks, click buttons, out comes the app.
If it works as advertised, why would any organization need programmers? The logical endpoint of low-code is to take development out of the hands of technical people entirely and put it under the control of business analysts reporting to customer-oriented managers. Flowcharts created by analysts could be translated into low-code instructions, then directly converted into the required software. Surely that would be faster and simpler, with less chance of misunderstanding or miscommunication?
But there’s a barrier to this goal, a significant one. Programming takes skill, experience, and a particular mindset. The most efficient programmers have tenacity, well-honed problem-solving abilities, work strategies based firmly on logic and the methodical elimination of errors, almost unbelievably fine attention to detail, and the ability to juggle dozens of factors (variables, routines, etc.) at once. They aren’t always paid well in return for these skills and talents, but that’s only because the people managing them don’t always comprehend what it takes to be a good programmer. It might look like easy work, but it isn’t.
Removing or reducing the coding part of the equation may have less of an impact than expected. Coding is the implementation of development ideas, but even if swathes of code are replaced with modular blocks, those implementation skills will still be required; they’ll just move up a level.
To use an example from computing history, the introduction of high-level languages didn’t put assembly language programmers out of work, nor did it eliminate the need for their skills. Those programmers simply applied their skills to the new languages. High-level languages did lower the barrier to entry to an extent, but that’s not necessarily a good thing. Having more programmers doesn’t automatically equate to better software. To quote Flon’s law, “There is not now, and never will be, a language in which it is the least bit difficult to write bad programs.”
That’s not likely to change with low-code development. If anything, we can expect even more bad software, because the barrier to becoming a “programmer" may be lowered once more. Business analysts dragging items into flowcharts then clicking Build App are likely to run into difficulties when their simplistic application meets the messy complexities of the real world and their own data sets. It’s telling that general descriptions of the low-code process run along these lines:
- Use visual IDE (integrated development environment) to sketch out the processes.
- Pull in various apps, services, or libraries to do the actual work.
- Do a little bit of coding if necessary to join things together.
- Deploy!
In all but the simplest of cases, Step 3 is likely to be the stumbling block, the point at which the low-code developer has to find a programmer to do the heavy lifting. It might start off as a request to add a few SQL queries, but for nontrivial applications it’s likely to snowball exponentially from there.
Some of the more cynical respondents to the low-code movement have made quips to the effect that they just can’t wait to see what wonderful new software emerges from marketing departments. Others have suggested that the whole idea was dreamed up by a gang of frustrated programmers in a sneaky attempt to show their managers how hard it really is to write decent applications. (Older readers might now be muttering “rapid application development” and other historical IT buzzphrases.)
Harsh, perhaps, but there’s reason behind the ridicule. Enterprises have separate departments for IT, sales, marketing, development, PR, and so on because that’s what works. Specialization tends to produce the best results, despite the complexities of cross-departmental communication. It’s unrealistic to expect PR people to be coders, or developers to be salespeople. People with nonspecialized skill sets aren’t unknown in the workplace, but they tend to be relatively inefficient. There are exceptions, but business analysts rarely make good coders.
So even with low-code initiatives, it’s unlikely that responsibility for development will move far from where it is now. Low-code may allow some applications to be built faster from a set of building blocks, but that concept isn’t new: It began decades ago with object-oriented programming and libraries. There isn’t a professional programmer in the world today who hasn’t reused chunks of old code in new applications. No matter how big the building blocks, they must still be assembled by skilled, talented, and experienced developers if the finished applications are to be useful, effective, scalable, and robust.
Enterprises should therefore be wary of seeing low-code as a cure for development bottlenecks. In the hands of skilled coders it should help to streamline some aspects of application development, but it can’t replace good programmers. Any organization planning to use low-code initiatives to shift development into nontechnical business departments may be in for a shock.
There’s no shortage of badly written, bloated, buggy, and useless software in the world. Adding more is an unlikely route to business success. If the productivity bottleneck in your organization is the rate at which in-house software can be developed, perhaps the most effective solution is to hire more skilled developers.
This story, "Low-code: What it can do for your enterprise—and what it can’t" was originally published by IDG Connect.