Technical Debt - Part 3: Quantifying
There are two key components to the technical debt equation: principal and interest. Quantifying both the principal owed and the interest payments being made are critical. Without a complete picture of the cost of the debt, calculating the return on investment (ROI) on resolving the debt is not possible. Understanding ROI is necessary in order to prioritize debt remediation efforts against other pending initiatives. We discussed the finite nature of technology resources (free cash flow) in Part 1 and why that resource has to be allocated carefully. Comparing the ROI of proposed technology initiatives allows organizations to compare projects objectively and maximize free cash flow.
To illustrate, let’s say we have a legacy application that leverages outdated technologies. Maintaining legacy applications can present many challenges. Enhancements typically take longer because the tools used to maintain the application don’t take advantage of more modern development environments and methods. Many legacy environments also fail take full advantage of advances in software engineering such as object orientation, integrated unit/regression testing, continuous integration and distributed source control. This can lead to decreases in quality and increases in complexity, risk and development time.
The amount of principal owed in this example is the cost of migrating the legacy application to a modern platform. If the cost of the target platform is $100,000 and the cost of implementation is $60,000 then the principal on this technical debt would equal $160,000. Quantifying the principal owed on technical debt is usually just an exercise in traditional IT project estimation. Gary Short proposed a formula as a starting point for calculating technical debt. The formula is a useful guide for calculating the costs associated with remediating technical debt but does not include interest expense.
- n = Number of resources required
- R = Rate (hourly average) of resource
- H = Hours required
- C = Costs associated with benefits, payroll, recruitment (usually ~40% of hourly rate)
- HC = Hardware Costs
- SL = Software Licenses
- MI = Migration and Implementation expenses (e.g. consulting engagements, training, etc)
The interest an organization is paying are the additional costs incurred as a result of the existence of technical debt. These additional costs are driven by a number of factors but most can be categorized as lost productivity and the exposure to increased risk. Much of the literature available on technical debt focuses on the productivity losses that debt brings to the table. I think the reason the literature focuses there is because it is the most visible and the easiest part of interest expense to quantify. For example, if you wanted to get a high level estimate of the productivity losses associated with maintaining the legacy application you could compare how long it took to implement a feature in the system and compare it to how long it might take in a different environment. Once again, this would consist of an exercise in project estimation.
The Risk Factor
The tricky part of calculating interest is measuring the risk the technical debt brings to the table. This isn’t a challenge unique to technical debt. Assigning a dollars to risk factors is difficult in just about every context. While a deep discussion of risk quantification is outside the scope of this article, my hope is that by highlighting a few examples it will provoke additional thought and discussion in your organization. The point to come away with here is that the increased risk associated with technical debt often has the greatest implications. The costs associated with lost productivity are usually the tip of the proverbial iceberg when it comes to the true interest cost.
Below are a few examples of risks legacy architectures often present. These risks aren’t always apparent but need to be estimated and included in the interest calculation.
- The lack of quality developers who understand the technology. This gap will increase as additional time passes.
- Increased turnover on technical teams driven by the lack of innovation.
- The additional cost and security risks associated with maintaining legacy infrastructure to accommodate the application.
- The inability to upgrade related platforms because of critical integration points.
- Being potentially unable to accommodate future requirements due to architecture limitations.
- Customer service implications associated with the inability to meet changing demands.
One unfortunate fact about technical debt is that the interest usually compounds. In other words, debt begets debt. Let’s say that your team receives a request from your business partners to create a mobile application that interfaces with the legacy application. Because the application was designed well before service oriented architectures (SOAs) became popular, your team has to create and maintain a separate application programming interface (API) to accommodate the request.
Any future enhancements that require modifications to the core of the system will require that you make changes in the system itself and the new API that was “bolted on” to the application. The existence of the original technical debt (legacy architecture) has created more debt (duplicated logic) and more corresponding interest payments (lost productivity, increased risk of defects, longer turn around on enhancements). This phenomena is analogous to compounding interest.
If we determine that the interest rate we are paying on the technical debt associated with our legacy application is 20%, the amount we will owe grows to almost three times the original amount in five years. We started with an estimated cost to remediate the debt of $160,000 but it will cost us approximately $430,000 to pay it back five years later.
This also means that in five years, we are spending $80,000 annually just to contend with the shortcomings associated with our legacy application. That’s about the cost of one full-time employee who is solely dedicated to servicing our debt. Hopefully this article has inspired some thought on how to go about getting a handle on technical shortcomings in your organization! In my next article we will look at some strategies for remediating your technical debt.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)