6 minutes
Software quality and technical debt have become vital points for investment professionals to tackle to keep their organizations competitive. These concepts are important for maintaining the long-term health of software systems in any organization.
At Software Improvement Group, we’ve been keeping an eye on how software quality and technical debt have evolved since 2000, observing trends and patterns that can have a significant impact on business operations. Finding the right balance between speed and quality is crucial, as poor software quality leads to slower time-to-market and increased costs, and technical debt can become a burden over time.
So what are the 5 types of technical debt?
Before diving in, it’s important to highlight that there are actually more than five types of technical debt, as discussed in my webinar with Charles Betz from Forrester (2022). In this article, I want to focus on ones that can seriously impact investment and are often overlooked during IT due diligence.
Let’s first look at at what tech debt is.
In 1992, Ward Cunningham, one of the authors of the Agile Manifesto, compared shipping first-time code to going into debt.
This debt involves trade-offs in software development when shortcuts are taken on code quality for immediate needs. A bit of debt can speed up development if repaid quickly through a rewrite. However, if left unpaid, a development team loses productivity. This loss of productivity is the interest that the team pays. It starts with a single line of code, which is generally fine, but when it’s not structurally dealt with, it could spiral out of control in the millions of lines of bad code in an enterprise.
Now let’s look at the specific types that shouldn’t be overlooked.
Architecture debt often sneaks in through antipatterns like ‘circular dependencies’, commonly called ‘spaghetti architecture.’ These patterns make it harder for teams or individuals to make changes to code in isolation or otherwise stated without impacting the work of others. The interest that a team pays on this debt is more communication, delays, and a higher chance of ripple effects of bugs. Architecture debt can also hamper a company’s ability to migrate systems to the cloud or utilize the cloud most effectively. All of this is crucial for modern scalability and cost-efficiency. For a private equity firm, running into architecture debt means that the expected benefits from cloud migrations might be delayed or require a lot of rework, increasing time to value and possibly lowering returns on investment.
A snapshot of our Sigrid® Software Assurance Platform
Data debt is the buildup of outdated or inefficient data models and storage systems. As a company grows, poor data architecture can impact scalability and make integrating diverse data sources a headache. For example, old data models can make it nearly impossible to harmonize data from new business units or incorporate data from an acquired company.
Take a private equity firm buying multiple healthcare practices, for instance. Each practice might use different electronic health record (EHR) systems, complicating the consolidation of patient information, billing records, and operational data. This lack of integration leads to inefficiencies, higher operational costs, and delays in realizing synergies from the acquisition.
Private equity firms should be aware that tackling data debt can be expensive, potentially affecting the overall profitability of their investment.
Technological obsolescence is about using outdated technology stacks and frameworks that are no longer popular or supported in the industry. This is problematic because it often means the expertise needed to maintain and develop these systems is hard to find. In addition, older generation technologies don’t have modern tool support, like testing frameworks or capabilities to change the infrastructure (e.g., from on-premise to cloud). New investments to revamp these aging systems can divert funds from other strategic initiatives. This is particularly risky for a private equity firm aiming to quickly modernize and boost operational efficiencies.
A lack of solid unit tests and comprehensive, automated testing protocols represents testing debt. This hampers a development team’s ability to make quick, confident changes, which is especially important during new investor-driven initiatives. Systems burdened by testing debt are more prone to bugs, errors, and regression, leading to delays that can affect an investment’s ability to hit projected milestones and financial targets.
The last one is a bit cheeky because I refer to the more classical form of technical debt. However, it still belongs on the list of ‘often overlooked’ because how often can an investor assess every line of code, which is often considered very sensitive intellectual property and not shared through a data room? I digress.
Maintainability debt is the complexity and redundancy within a codebase, contributing to the classic technical debt scenario. Complex and redundant code makes future development harder and also substantially increases the cost of maintaining the software. For an investor, high maintainability debt means higher operational costs and longer lead times for rolling out new features or updates. This delays the achievement of strategic objectives, reducing the potential return on investment.
These two systems have similar functionality: the left contains a below-average amount of technical debt, and the right has an above-average amount. According to SIG’s research, based on an analysis of over 200 billion Lines of Code, the difference in productivity between these teams is a factor 2 times at a minimum.
Software quality shows the current and future value software brings to the company. There are many interpretations of what ‘quality’ means, and this is why international standards exist. To objectively assess the technical health and worth of these assets, it’s important to use international standards like ISO25010. This standard lists quality traits for software products, offering a framework to continuously assess their condition.
Using a methodological approach to measure software quality and overlaying with a software economics model, you can quantify the effort—and thus the costs—associated with remedying technical debt. Only by establishing the amount of technical debt and analyzing its impact on business operations can investors make informed decisions to rectify instability, customer dissatisfaction, and security risks while counteracting competitors’ potential to deliver value more swiftly to the market.
Identifying and measuring technical debt is just the beginning; the real challenge is managing it effectively.
When managing technical debt, make sure to:
Remember: it’s important for IT leadership to promote awareness of technical debt across the organization, making its management a core part of the development process rather than an afterthought.
