Low-code app development tools have existed for over 20 years, but for a long time they were a niche concern. The tradeoffs they brought were too big for many people to embrace. Now we have different circumstances, though, and the technology’s improved, too. It looks like low-code app development tools will go a lot further second time around.
I started out as a technology industry analyst in 1995. This either makes my experience of working through past technology waves hugely valuable, or it makes me an irrelevant dinosaur (depending on who you talk to).
One of the things that my long teeth give me is a sense of history, though, and that’s worth knowing when you look at low-code app development tools.
Pass 1: visual programming
When I took my first position in this profession, my topic coverage area focused on ‘fourth-generation languages’ (4GLs) and ‘client-server’ development tools. I covered everything from Visual Basic to IBM’s VisualAge. Back then there was a diverse collection of vendors all proposing to solve the same problem: improving development productivity for business software, above and beyond what was (at the time) more mainstream practice: developing in COBOL, C, C++ and so on.
In the mid-1990s, the value of these tools was built around the ability to use abstract ‘visual programming’ to specify application structures and behaviours rather than writing code by hand. This was still relatively early days for GUIs in mainstream business computing, and the new tools took advantage of GUI technology to make it possible to specify application structures and behaviours using drag-and-drop techniques. These abstract specifications would then pass through a code generator, or be interpreted at runtime in a virtual machine of some kind.
This same era saw an explosion in platform technologies as client-server computing really took off, and many of the tools available also competed based on their ability to run cross-platform – so you could specify an application once, and deliver applications across MacOS, Windows (various versions), Unix (various flavours), and perhaps even OS/2 or OS/400 (ahem).
Pass 2: low-code app development
Looking back, it was perhaps inevitable that although these tools delivered a lot of value in many scenarios (though there were always situations where they would struggle), they fell from fashion at the end of 1990s. Industry attention turned on the one hand to dealing with the Y2K issue, and on the other hand the lure of Java (cross-platform delivery, a language that C and C++ developers could cross-train for quickly, and an open community approach). Very few hit critical mass.
After a nearly two decades in the wilderness, though, tools that help organisations deliver business software quickly are back in favour – as ‘low-code app development tools’.
It’s important say here that I’m not dismissing these tools: in fact, it’s quite the opposite. I’m a huge advocate. I do think we can learn some important things from the technology’s heritage, though.
At its core, the strategy of low-code app development tools today is the same as that of the visual programming in the 1990s: use abstractions (often visual abstractions) to specify application structures and behaviours, and use the resulting specifications to generate application code, or interpret those specifications at runtime. The potential value is also very similar: deliver application functionality quickly, and make it as easy as possible to change functionality over time. (The cross-platform element is similar, but this time it’s about handling the vagaries of mobile and web).
What has changed, for a great many organisations, is the business and technology context: we know that digital transformation has many flavours, but we also know that the vast majority of organisations, across industries, are moving to find ways to span silos of data, function and people; build out and integrate digital channels; automate and streamline operations; create more seamless, virtual workplace environments, increase the productivity of mobile workforces, and so on. In short, pretty much every organisation has a problem with delivering applications fast enough, and many of them know it.
Additionally, we can’t overestimate the importance of today’s commercial models and wrappers, which increase the accessibility of these technologies. In the 1990s enterprise software was licensed perpetually, with high upfront cost, and delivered on shiny disks; now, a lot of it’s rented over wires and – at least in early stages of an investment – can be purchased with a credit card or even used for free.
Finally, what has also changed is that many tools vendors have become better at realising their technology’s core limitations and providing compensating mechanisms.
All abstractions are leaky; visual model-driven development can only ever take you so far. There will always be some situations where you have to unplug yourself from the matrix. Back in the 1990s the state of the art in integration made life challenging in these situations; now, with the prevalence of open, documented APIs, the prevalence of sophisticated open UI frameworks, data access and integration frameworks and so on all make dealing with edge cases much simpler.
This last bit is the bit that you need to think carefully about.
Three types of use case
We know from our research that today’s low-code app development tools actually get used to address three different kinds of use case: application prototyping, small-scale ‘departmental’ app development, and enterprise app / process extension. Depending on the kinds of use cases you’re looking at addressing with these tools, you need different things.
Prototyping, for example, doesn’t require tools with lots of extension/customisation hooks, open APIs and so on. The more ‘enterprisey’ your use cases, though, the more extensibility and customisability are important – and the more it’s vital that these tools can fit into your organisation’s established development and delivery workflows – and skillsets.
If you want to take advantage of the value that low-code app development platforms can give you, you need to consider the problems you’re looking to solve first, and realise that different tools are good at solving different problems. They’re not all the same.