Low-code: what it can do for your enterprise - and what it can't

Building software with low-code visual tools can save time, but won't magically fix underfunded development departments

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 off-loading 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.

Appian CEO believes hobbies hold the key to success at work: Meet the tech CEO who creates war games as a hobby

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, since 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:

1. Use visual IDE (Integrated Development Environment) to sketch out the processes.

2. Pull in various apps, services or libraries to do the actual work.

3. Do a little bit of coding if necessary to join things together.

4. Deploy!

In all but the simplest of cases, step three 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 non-trivial 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 buzz-phrases under their breath.)

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 non-specialized 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 non-technical 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.