Low-Code Platforms: Don’t Buy the Hype

I recently contributed to a blog post with a set of predictions for technologies that would make an impact in the next five years. I’ve been looking at a lot of other predictions and they all include something I didn’t: low-code platforms. To be clear, this wasn’t an oversight on my part.

I don’t buy the hype.

I’ve been developing systems for a long time and this idea comes around every 10 to 15 years. In the 1970s and 1980s we had computer-aided software engineering tools like AD/Cycle, IEW, ADW, and Cayenne. In the 1990s/2000s we had the rapid-application development/fourth-generation programming languages like Forte, Rational, PowerBuilder, and Progress 4GL. All promised exponential improvement in delivery times.

But they all disappeared within a few years. Why? There are many reasons I don’t think these platforms live up to the hype or are good solutions to most problems. Here are my top seven:

1. The Bottleneck in Delivery Cycle Isn’t Development Time

Software delivery includes a much longer lifecycle than just developing code. Teams must define what the software should do, develop it, test it, debug it, deploy it, train internal users or market to external users, modify and support it, etc. The time spent defining the problem, determining the requirements, funding the work, waiting on resources, debugging performance issues, learning from users and pivoting your solution, etc., often greatly exceed the development time. These other barriers to throughput are often difficult people or organizational issues. It’s common to spend 75% of the delivery cycle to be spent on non-development activities. So even if these tools do improve development time, the overall impact is small relative to the investment required.

2. Business Users Aren’t Trained in Efficient Algorithms

Low-code platforms promise that business users can create applications and customize them to meet their needs—eliminating the need for developers. But, even with these platforms, there is a need to write some code. Even with drag and drop interfaces, business users build “algorithms” to solve problems. This can introduce bugs, performance problems, and other issues that must be resolved. There are usually more of these issues (especially performance issues) than in a traditional solution because business users don’t have the background in algorithmic thinking, complexity theory, or exception handling. For example, take the following written in a popular low-code environment:

Clearly, if there are a large number of rows in the database, this application will perform poorly. The increased number of issues and poor visibility (see below) ultimately increases debugging and issue resolution time, often negating any savings in development time.

3. Visibility

These tools often don’t provide the detailed visibility into runtime operations that are necessary to determine where issues or performance problems are. For example, debugging tools can be lacking and logging of internal issues can be difficult or limited. This greatly increases the time it takes to find and resolve issues.

4. Support for Source Control and Multiple Environment Deployments

Solutions often need to be built in one environment, integrated with other systems and tested in a different environment, and then deployed to production. More complex deployments may be necessary for load test, training environments, beta environments, etc. Source control and continuous integration/continuous delivery (CI/CD) tools are used to manage which versions are going to be deployed to which environment.

Most of these low-code platforms do not provide cost-effective support in multiple environments past basic test and production environments. Furthermore, they do not provide methods to track changes and migrate them between environments. Finally, the ability to refresh, mask, or mock data in lower environments is often missing.

As a result, users of the low-code environments will often have to manually redo changes, deploy changes after only limited testing, and rely on small, manually curated data sets. Complex problems or issues related to volume are often not found until production.

5. Open-Source Innovation Rates

The open-source community builds new frameworks or tools that solve problems. The rate at which these tools are created and improved is staggering. Just search for “JavaScript framework” and you can see the explosion of new frameworks in the last couple of years (Angular, Vue, React, etc.). These frameworks are written by developers to solve common problems and have a much greater impact on development velocity. With potentially hundreds (or thousands) of developers contributing to these open-source projects, they can outpace the development of commercial products where research and development teams are limited. Open-source solutions also offer an attractive cost savings over the low-code platform.

6. Vendor Lock In vs. Portability

This is one of the biggest concerns our clients have. Unlike a standard application (which can be packed up in a portable format and moved from cloud to cloud to on-premise infrastructure) these applications are tied to the vendor’s platforms and runtimes. Migration can be painful or even prohibitive.

Cautionary tale: I have one client who has an application that was built over eight years with one of the fourth-generation programming languages listed above. Their cost of support for this platform has gone up exponentially as the vendor has lost market share. Finally, they received an end-of-life notice and are struggling to migrate to a new platform.

7. Talent Availability

In today’s environment, developers are in high demand. They want to expand the skills that are most valuable in the marketplace, like JavaScript, Python, etc. They don’t want to invest in learning a platform with limited features, limited control, and low potential for new opportunities. And most business users are interested in furthering their careers by improving their leadership skills, moving to people management or product management roles, and orchestrating business value. They often don’t want to spend valuable time learning to drive a pseudo-code platform.

The result of this is that developers with experience in these platforms is limited so they can command higher rates—usually negating any savings from reduced development time.

Moving Forward

Although there are probably good uses for low-code platforms—I wouldn’t rely on them for business-critical platforms. To be fair, today’s platforms (Pega, Mendix, SFDC, etc.) are trying to address some of these limitations. For example, Mendix allows deployment via common CI/CD tools to different environments and Salesforce.com has launched the Developer Experience (DX) tools. In other words, these solutions are moving their platforms towards being more like traditional development platforms.

So, if you are frustrated by slow delivery, we would recommend looking across the entire software delivery lifecycle and find out where the actual bottlenecks are. It’s almost always necessary to address the entire value stream to get the type of throughput, velocity, and quality companies are looking for. If you need help doing that analysis and finding solutions, let us know at findoutmore@credera.com—we’d love to help.

• Open Source
• Technology
• Development