There just aren’t enough developers to go round. Businesses have long understood that software development can be complex and costly, and not everything within the enterprise is mission-critical or customer facing. Not all of your applications need to be bulletproof or come with a slew of features; sometimes basic, working software is enough to enable a team or department to become more productive and deliver more value. You can see how businesses have sought to deal with the fact that they can’t build everything themselves with things such as packaged apps, outsourcing and the like.
The latest ‘silver bullet’ comes in the form of low code platforms: an environment programmers use to create application software through graphical user interfaces and configuration instead of traditional computer programming. A typical low code platform will provide a drag-and-drop development environment and model-driven logic to enable creators to build an application that solves their particular need.
The premise is simple: you don’t need to waste your dev teams’ time on limited-use apps; simply get someone that understands your business to create the apps they need in the low code environment. Low code promises to clear up backlogs, spark innovation and build up a citizen developer workforce.
It’s an approach that has many fans, and just as many critics. Analyst house, Gartner, for instance, predicts that by 2024 two-thirds of application development will be done solely on low code platforms. This doesn’t imply traditional software development output will drop dramatically, but that a greater proportion of new applications are developed on low code platforms.
To get the best out of any technology, it’s necessary to dig behind the hype and criticism to properly understand its strengths and weaknesses, and the highly polarized content can make this somewhat difficult. On the one hand, when used correctly, low code could be a promising addition to an organization’s technology toolkit. At the same time, the concerns brought up by critics — who are generally software developers — shouldn’t be outright dismissed. A balanced perspective is needed to understand whether low code is right for your organization.
Where low code gets the job done
In any typical enterprise, there are a multitude of business-enhancing applications that don’t require full-stack development teams, where practices such as continuous deployment, end-user acceptance testing, or test-driven development might be overkill. Think of a bank that wants to introduce a simple, in-branch, customer service touchscreen or a simple branch employee mobile app.
We see that the following app characteristics might fall into this sweet spot for low code:
- The application is mostly a simple UI, and you can take advantage of building on top of newly developed digital platforms or APIs in the enterprise
- An off-the-shelf version isn’t available
- Off-the-shelf applications are too complex or too expensive
- The business problem to be solved is simple and straightforward
- The resulting systems architecture for the low code application fits within your overall IT estate
- The low code development team can be small, and doesn’t need to coordinate too heavily with other teams
Running up against the edges
For those IT leaders contemplating low code deployments, the real challenge comes from thinking about the edge cases, where we run outside of the low code sweet spot and into the messy reality of the problems for which low code may not be suited.
Take complexity. Few applications are ever created to be complex, but the reality of today’s enterprises is that complexity is a part of life. Low code environments tend to use a visual metaphor to describe logical program flow, and once the ‘diagram’ for the code becomes too large it becomes very difficult to understand. As a result, there’s an upper boundary on the complexity of logic that can reasonably be implemented in a low code platform.
This is a problem that many of the low code platform providers recognize. Their solution: if anything is getting too complex, you can drop down into custom code. And this is where the alarm bells should start ringing.
Anyone that’s had the experience of customising a COTS package knows the perils of straying too far from a vanilla install. If you start modifying the code behind your low code apps, can you be sure you’ll remain on the upgrade path? And if not, are you going to regret not bringing your software professional in to deliver a custom solution up front?
Security and testing
It’s not just migration paths. What about security? We all know about the multitude of risks facing today’s enterprise, but when you don’t really know how your applications were developed, how can you understand where your weak spots might be?
In an archetypal application development process, you can implement a testing regime to bug bash and check the quality of your code. When you’re in a low code environment, you’re reliant on both those doing the application development to test their results and also on the tooling provided by your low code partner. In many instances we’ve encountered, the tools for testing low code applications fall short of what we’d expect.