If Low-Code Platforms Aren’t the Answer, What Is?

Previously, I wrote this post explaining I didn’t buy the hype around low-code platforms. I also promised I’d provide some better alternatives.

Starting With “Why?”

The first thing I need to clarify before discussing alternatives is “the why.” That is, if I’m going to propose an alternative to low-code platforms, it needs to address the same challenges the low-code platforms claim to address. What are those?

Today, software is critical to the success of every business. As Marc Andreessen famously stated:

“Software is eating the world. In the future every company will be a software company.”

I won’t go into the reasons for this, as I assume that you, gentle reader, agree (or you wouldn’t be either thinking about low-code platforms or reading this blog post about alternatives). But, most companies struggle to deliver technology effectively. Even after decades of advances in technology and methodology, research shows over 50% of projects will cost 189% of their original estimates and over 30% will be cancelled outright. The root cause can be traced to three primary issues:

1. Speed to market: Building software takes too long and is too expensive.

2. Quality issues: Applications have too many issues, are slow, and don’t meet user expectations.

3. Technology talent: There is a shortage of qualified developers who understand the business needs.

These three issues are what the low-code platforms promise to address.

• Speedy solutions that can be delivered “in days” without engaging the slow, bloated technology team.

• Quality solutions that won’t be plagued by bugs like “normal” projects, and by putting the “user in control,” you guarantee the solution meets business requirements.

• And you can eliminate resource constraints by using “citizen developers” from the business and the business won’t have to vie for high-skill developers who don’t understand the business needs anyway.

Sounds promising, but as I explained in last week’s article, low-code solutions are not the answer.

So how do we get high-speed, high-quality, and quick/low-cost development in a time when resources are constrained? Here are some practices we’ve found that help. (Note: Agile, Lean, and DevOps proponents will immediately recognize these practices, but I’m trying to avoid these labels and focus on actual actions that help.)

Challenge 1: Speed to Market

Eliminate Bottlenecks

First, outline the entire process to deliver software—the so-called “value stream” or “software development lifecycle” (SDLC), including project initiation and funding, requirements, development, testing, deployment, change management, etc. Map this out in detail and understand where the bottlenecks are. Focus on addressing these bottlenecks first because as long as bottlenecks exist, changes in other areas won’t yield improvement and may make the situation worse by overwhelming other parts of the value stream.

Work in Small Increments

Second, instead of building software for months and then launching to see what works, break the problem down into small pieces that can be independently deployed and validated. This allows companies to discover issues, get feedback from end users, and course-correct if necessary.

For example, we once had a client who wanted to update their mobile app to add support for mobile wallets (Apple Pay, Samsung Pay, Google Pay, Venmo) and direct bank draft (eCheck). They also wanted to implement a loyalty system where users could pay with points they earned. They rushed to rework the entire payment processing system from the ground up—changing it almost in its entirety. The result was over a year of work (which was delivered six months late). Worse, the quality issues on the rollout caused several outages, eventually requiring the entire system to be rolled back. The team had essentially lost years of bug fixes by replacing everything at once. (Or, as my colleague Josh Hamit said, they essentially recreated years of bugs.)

This “jack up the radiator cap and slide a new car underneath” approach almost never works. A better approach would have been to just implement one of these changes, e.g., ApplePay, and then incrementally work through the rest. This not only realizes some of the benefits of the effort but provides lessons into what is necessary to make additional changes, reducing the overall risk.

Focus on Architecture

Third, you need a ruthless focus on architecture. This probably deserves an entire post on its own so I won’t go into too many details, but most systems have incurred years of “technical debt.” This is often the source of many of the issues in terms of speed (and quality for that matter). I’m not suggesting there aren’t some cases where you need something quick and dirty. But you must quickly “pay down” the debt or you will spend all your time and efforts “servicing” the debt.

Automate, Automate, Automate

Finally, many of the time-consuming parts of the development can be automated. Testing and configuration management are often the source of many of the bottlenecks in the process. For example, manually testing can take weeks or months to validate even small changes to a mobile app due to the number of permutations of devices and versions that must be supported.

Challenge 2: Quality Issues

Automate Testing

As mentioned above, automating these steps not only improves the time to market, but can help improve quality by reducing manual efforts. This is especially true for configuration management. When complex applications are deployed there can be hundreds of values in property files, operating system and platform settings, data values, or security settings that must be applied. Relying on manual check lists and runbooks invites manual error. Not only do manual errors cause issues, they create unplanned work for development teams to resolve, which takes time away from other development efforts.

Manage Test Data Relentlessly

One item that you may not expect to find on this list is test data management (TDM). This is the process of managing known data sets that represent all the test cases you want to automate. Without TDM, there is no way to ensure that automated tests can run successfully. Common approaches such as taking snapshots of production databases can increase the time to market (waiting for someone to create the snapshot), expose security risks (moving production data to test environments), and can cause many of the tests to be reworked to match the new data. This can often take just as long as manual testing!

Challenge 3: Technology Talent

Addressing developer resource constraints (both availability and skill levels) isn’t quite as easy. It can take much longer to make changes to the “people system.” Plus, it’s very disruptive when good talent leaves: It disrupts projects and requires time to train/backfill their replacement. I’m not an expert in recruiting, talent developing, or employee engagement, so I won’t pretend to be. For a better resource, check out this six-part series by Kevin Erickson, Grace Lee, Cameron Weinert, and Ben Grotta. But there are things that we can do to help from a technology perspective.

Build Technology-Focused Career Paths

As a firm that does complex technology transformations and systems implementation, it’s often hard for Credera to find qualified developers, engineers, and architects. We’ve had to go outside traditional sources of recruiting to attract talent. To help prepare these resources, we’ve developed technology-focused career paths. We’ve also created many coaching methods to train our resources on these career paths. And we pay bonuses for taking a pre-approved set of external classes where they exist. I admit that developing this training program was a much bigger commitment than I first envisioned. But the benefits have far exceeded expectations.

We also work a lot with the campuses we recruit heavily from to help develop courses and students for technology careers. For example, we worked with Baylor University to develop a class that delivers a software project in small groups using many of the techniques above. We then have our consultants act as class mentors, volunteering to work with teams weekly to provide feedback and direction.  We are now working to roll this program out to other campuses who want to partner.

Finally, we focus on developing non-technical skills of developers, such as business acumen, understanding the client’s business model, structured writing and speaking, and data analysis. These skills make developers more effective at communicating with business teams, understanding the problems to be solved, and communicating options.

People often worry about spending time to train people only to see them take another job. We don’t worry about this.  As Henry Ford said:

“The only thing worse than training your employees and having them leave is not training them and having them stay.”

Documentation and Onboarding

Documenting systems sounds boring and may not seem to belong on this list. But it’s critical for new developers to get up to speed. We treat this documentation like code in that it is reviewed, updated, and published with each release of the software. As part of this documentation, we also create and automate development environments, databases, etc., so that developers can be up and running in a matter of minutes. Our goal is to have a new developer fully up to speed inside of a week. Without this, unexpected departures and life events can delay projects by weeks.

Reducing Unplanned Work

“Reducing unplanned work” is, again, something you might not expect to see in this section. It’s really an outcome from many of the practices above (automating testing, focusing on architecture, managing test data, etc.) By doing this, developers have:

• Fewer late nights debugging production issues.

• Fewer mundane, manual tasks.

• Less rework of poorly designed solutions.

This impacts developer quality of life by reducing burnout and stress. Research by DORA/Google show implementing these practices make employees twice as likely to recommend their employer.

Put It Into Practice

There is no silver bullet to being effective at software delivery. It takes a coordinated approach across lines of business, marketing, technology, finance, and even human resources to get effective at implementing and using technology to drive business outcomes. As I outlined in the previous article, low-code platforms not only don’t address the fundamental issues, they exacerbate the problem.  Hopefully, this article has clarified some better approaches. If you have any questions or other alternatives, feel free to reach out at findoutmore@credera.com.

• Open Source
• Technology Development
• Low Code