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.
Complexity
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.
Whatever application development you want to do, it’s essential that you can verify that it’s working properly. Your entire test strategy needs to be able to support the level of risk established in the original use case. We often come across the assumption that if you’ve written less code, as you would with low code, there’s less chance that something can go wrong. But we think it’s prudent to be able to test that.
Integration
Few enterprise applications exist in complete isolation: most will need to integrate with other systems and be able to consume data and expose it to those systems. Increasingly, we’re seeing low code platforms promise they’ll enable you to build the sorts of APIs you’d need to integrate successfully.
That’s probably going to be okay if your low code app is only integrating with a handful of other systems. But the complexity of managing APIs when you’re having to integrate dozens of systems shouldn’t be underestimated. And it’s probably worth understanding what documentation you’ll get from your low code platform. Will it enable you to manage your APIs in the long term?
Lock-in
One of the more unusual questions we’ve had from clients recently is: “What do we do if Google goes out of business?”. The chances of it happening appear to be vanishingly small, but it’s a question that many leaders in regulated industries are being forced to consider. Because no matter how likely any business-impacting event would be, they’re required to have an answer. And the same is true when it comes to low code.
Many low code providers can provide the reassurance that in the event of needing to migrate platforms, you’ll be able to export your application as generated code, and recompile your applications from there. That’s probably a good start, but we’d urge anyone running a low code application that has significant impact on their operations to test their ability to do this successfully and to check out what the resulting code looks like. It might be able to run, but would you ever be able to make changes to it? Generated code in these situations is often algorithmically correct, but unreadable for humans. It will execute properly but forget about ever changing it in a meaningful way. Much like the disaster recovery adage: you don’t want to wait until you need it to find out whether your backup plan works.
Scaling a success
Everyone loves a success story, but when it comes to low code, success can bring its own set of problems. Go into any enterprise, and you’re likely to find examples of applications that started out small, but have proven their worth over time and spread throughout the business. And given that likelihood, we think it makes sense to plan for that when using low code platforms.
If one of your teams creates something compelling within your low code platform, what do you do if it really takes off? How will you handle integration, risk assessment and testing? How will you handle feature requests that increase the complexity way beyond the original use case? It’s all too easy to assume that you’ll be able to sandbox low code development and treat it differently than your other software assets. But the reality is that you need to plan for what happens when a low code app becomes mission critical.
Low code in practice
Let’s consider how this might play out in practice. For instance, say you want to create a package tracking app for your delivery service. The application itself is relatively straight-forward: at each point on the delivery chain, from warehouse to drop point, the package will be scanned, and that information should be presented to the customer via a web app.
Before you set about building this app using your low code platform, you might want to consider scalability. Potentially, you could have millions of users for this app — have you checked that your back-end (and the low code platform itself) can cope with that level of demand?
You might also want to consider the UI. You can reasonably expect that there’ll be a high degree of variety in the types of devices that your customers are using. low code platforms are designed to support this, and their built-in UI widgets will work across devices. But what about the specifics of the UI for parcel tracking? If your low code platform doesn’t have a timeline module, you’re going to struggle. If the timeline module doesn’t behave exactly how you’d like it to, you might be forced to either live with it, or drop down into custom code to tweak it to your liking.
Even once you’ve overcome these hurdles and have your app successfully deployed to millions of users, you still face challenges. As the world turns to online shopping, return rates are becoming an ever-more pressing concern for retailers. Can your delivery app integrate with the systems of your retail partners and help them track which packages are being returned? If it’s just one retail partner, the answer may well be yes, but as more and more partners come on board, the number of integration points rises — and the task of managing that complexity becomes exponentially more difficult.
The low code safe zone
There are many good reasons why organizations want to use low code but we’d always advise doing so within a set of clearly defined guardrails. If you have an application that would typically need two or three developers, where the business logic is pretty constrained and the app will only integrate with a handful of other systems, you’re probably in the safe zone.
Once you go beyond those boundaries, you might still want to make use of your low code platform — but you’ll want to seriously think about potential risks and the steps you put in place to mitigate them.
Lastly, you might think about that safe zone as a function of team size. This isn’t intended to be too prescriptive but we do think that once you have more than six people working on a single app — including those on testing and the like — that the app is likely to start becoming too complex. Low code can undoubtedly give you some quick wins and prove it’s worth in the enterprise. Just be wary of trying to do too much with the platforms.
This article was updated in May 2021. We made some minor changes to the original to make some things more clear and up to date. Also, we are directly recognizing the polarization of the narrative around low code, and the need of an objective perspective.