Ward Cunningham introduced the technical debt metaphor as a method to highlight the potential for higher costs in product development from postponing some work on software in order to release other parts faster. The comparison between financial debt and the term technical debt was meant to demonstrate the eventual need to complete postponed work and repay the principal of delaying it. Technical debt also alludes to the possibility that interest costs, associated to postponed work, can become so high that they impede any other important work from being done on a project. For these reasons, technical debt is a useful concept – as it clearly communicates the danger of postponing work. However, metaphors often conflate two comparable situations, to two identical treatments of similar situations. This can be avoided in the financial debt/technical debt coupling, by using the financial metaphor to identify the economic forces behind technical debt.
In the simplest explanation of financial debt, where all of the principal is repaid at the end of a loan period and interest is paid regularly until the principal is returned, there are three economic consequences to consider.
The summation of these consequences is that financial debt has very specific and known consequences – everything is calculated with certainty when this type of debt is taken on.
If the similarities between financial debt and technical debt are extended, there also three economic consequences to take into account. However, these consequences have different results than those of financial debt.
As with financial debt, it is only economically sound to take on technical debt when the cost of the burden incurred is lower than the benefits gained by deferring work. In order to understand the economics of technical debt there must be a keen awareness of the costs that come into play and the uncertain nature of these costs.
This post delineates the economics behind technical debt through a variety of calculations.
The case presented, for calculating the costs of technical debt, is whether to release a product with technical debt immediately, or spend 2 months and $40,000 to release a debt free product. To begin this process, assume that there is $40,000 of deferred development expenses in a year 1, and $60,000 spent per year in maintenance costs for this product. If then, the work is deferred until year 5 and paid back at twice the cost of the original effort ($40,000 x 2), an attempt to save $40,000 in development costs actually ends up costing $340,000.
This may seem like a cogent analysis of the costs of technical debt but there is a major factor that is missing in the calculation.
In the first iteration of analysis, the missing element in the calculation was the cost of delaying the release of the product for two months. Cost of delay (COD) is a quantifiable measure and pertains to both deferred and non-deferred work. So in addition to costs set up in the first round of calculation (deferred development expenses, maintenance costs, and payment of deferred work) the COD on non deferred work, at $250,000 per month, needs to be included. Deferred work, in this case, comprises of 3% of the product value and 3% of the total cost of delay ($250,000 x 12 months x 3%) and therefore amounts to $90,000. The delivery of non deferred work, two months early, at 97% of the product value ends up saving $485,000 ($250,000 x 2 months x 97%). Given these numbers, the result is more informative on the costs of delaying work – delaying the delivery of the extra 3% of the product value incurs no net costs for 3 years. This is until the savings from releasing 2 months early are spent, and at the 5 year mark the deferral of work, and its eventual repayment, costs $305,000.
While this calculation is able to capture the benefits of postponing work, it does lack a recognition of the uncertainty of the costs related to postponed work.
The assumption that some of these costs are uncertain should be employed when calculating the debt incurred from deferred work, and the calculations should be adjusted to take into account the likelihood of these costs. Therefore, in this example, all the costs associated with deferred work will be weighted at a 50% probability of occurrence. When taking into account the uncertain nature of costs, the results of deferring work can be justified for a full 5 years, although the cumulative benefit of the postponed work decreases every year. This result is based on the other calculations as 3% of the product value is being deferred at 50% rate of probability, meaning that instead of $90,000 COD on postponed work, it will be $45,000. This probability also applies to maintenance costs on deferred work lowering costs from $60,000 to $30,000.
These calculations should not be interpreted as a universal rule for technical debt calculations. In another case, where the deferred work accounts for a higher percentage of product value, or the probability of payment is higher – the benefits of postponing work may not be as lengthy or as strong as in the example presented above.
As demonstrated by the variance in the calculations above, depending on what is considered when analyzing a decision to take on technical debt, there are many concerns that need to be implemented and taken into consideration:
The goal of this post is not to discredit the utility of technical debt as a metaphor, but serves to highlight that reasoning based purely on a metaphorical idea can lead to poor economic decisions. Adding some math, and heeding the use of the term technical debt due to bias, can benefit a project. This should be especially beneficial considering that stakeholders in a project respond well to and rely on economics in making decisions. Framing choices in economic terms can benefit a project by communicating options in a language which decision makers understand.
To read this full post and see the full rendition of the calculations mentioned above visit here.