Demystifying Technical Debt for Deals

To some extent, beauty is in the eye of the beholder when it comes to coding. Scanning the source code will tell you how many thousands of lines of code (‘kLoC’) there are. You can check the percentage of bespoke vs ‘off the shelf’ code to get an idea of software quality. But you’ll still need to interpret the findings to find the ‘So what?’ from a deals perspective. For example, what’s actually being used and what’s defunct?

Well-written code is easy to read and straightforward to follow, which makes it easier to build on and adapt. Difficult code is harder to work with and follow, and therefore more expensive to maintain. This can be caused by poor code hygiene (such as leaving dead pieces of commented code around), unstructured code (or ‘spaghetti code’) and a lack of code documentation.

A blast from the vernacular past, but still relevant. Bloat can happen when progressive versions of software simply pile functionality and code on top of what’s already there, leading to loss of performance through higher consumption of resources for limited benefit. Or when the source code is unnecessarily long or complex for what’s needed, making it slow to execute and/or wasteful of resources.

Many platforms have been built and ‘tweaked’ over years or decades with a mix of coding languages and different versions of the same language. Over time, this becomes more and more difficult to manage. Which bits of the codebase do you need to update, when, and why? What’s the impact on new functionality?

Sometimes, we see archaic languages like COBOL, JSP or PROGRESS being used. Unfortunately, there’s a limited pool of people who know how to use these languages. They’re difficult to learn, expensive and can’t be adapted for modern deployment models.

We usually see this problem with older platforms that haven’t been properly maintained, or in businesses that have grown through bolt-on acquisitions. In both cases, the solution is to go back and upgrade or standardise the language mix.

Out-of-support database types or operating systems count as tech debt. Apart from the clear security risk, they can also stop you getting the cost and performance benefits from modern platform-as-a-service (PaaS) tools and can be challenging (and costly) to update.

Open source components are convenient, but they need to be monitored, tracked and updated to patch security flaws, just like any other programming language. As an aside, you also need to understand the IP licencing, given the possibility that you might not own all of your source code or might be required to contribute to the open source community.

20 or 30 years ago, what we now call ‘legacy’ applications were installed on a server in a chilled room somewhere in the office. Despite the prevalence of modern, microservices-based architecture, these monolithic apps are still commonly used. While it is possible to adapt them for today’s cloud infrastructure, it’s expensive and impractical to do so, particularly when it comes to scaling them up.

We looked at an education software business that was rolling out customer deployments using a cloud platform, but hadn’t re-engineered the source code. This meant that while the plan could be delivered, the infrastructure cost heavily impacted the margin because the business had to buy capacity in ‘blocks’ ahead of receiving revenue.

The questions here are: Can the platform meet the scaling needs of the business plan? And can it cope with the short term peak load traffic requirements? A ‘no’ to either is sure to be a business plan blocker and an example of tech debt.

This is how usable your product is from the customer point of view. For a B2C product, we might ask: Is it intuitive to use? Are you asking more or less questions than your peers? Are you losing customers at crucial points, like in a software demo or at checkout?

While this is an area that’s somewhat subjective, there’s a usability component to any software build—both for customers and operators. Issues with UI and UX will slow you down and contribute to tech debt.

In the world of testing, risk management can get philosophical. Organisations weigh up failing fast vs failing safe, while others might choose to do the minimum necessary and deal with the consequences later. Some key questions to consider are:

• Is the level of testing sufficient, or does it actually allow systemic build-up of tech debt?
• Does the complexity of the technology mean that the testing and release process is overly difficult, unwieldy, or prone to error or rollback?
• Is testing automated or could it potentially be?
• Could you use a third party to test (at least in the short term), leaving all your resources to focus on development?
• Is the release cadence in accordance with support policies and will you be able to get your customers to use the latest version?

If the business plan envisages growth in new country X, can the platform support that? Are there any localisation requirements (e.g. language, currency)? Do data residency requirements mean the infrastructure needs to be located differently? Does the system meet current regulatory needs or can it be adapted to comply with them? Will you need catch-up development to do this?

Skills and specialisms evolve alongside software languages. For example, Fortran and COBOL are two first-generation development languages that were developed in the 1950s. Today, it’s very difficult to find skilled people who can code in Fortran and COBOL, but they’re still in use. Niche issues like this can present an unexpected challenge for security and maintenance. So we consider them an example of tech debt, along with other team-related factors like cost and physical location.

We reviewed a legal services software business whose platform was based on Progress (AKA OpenEdge since 2020). Most of the core development team were approaching retirement age, and the business wasn’t able to find new team members at a commercially reasonable rate. This meant they had to consider an expensive refactoring of the platform core, or broaden the talent search globally along with the cost and operational implications that would bring.