The Economics of Technical Debt

by

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.

  1. The immediate benefit of access to the principal, has certain (known) magnitude and timing.
  2. The obligation to pay back the full principal at a specific time is of certain magnitude of timing.
  3. The future obligation to return 100%  of the principal at a specific time is of certain timing and magnitude.

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.

  1. The immediate benefit of postponing the expense of development effort may result in savings of both expenses and cycle time; but the magnitude and timing of these benefits is uncertain.
  2. The ongoing obligation to pay economic rent on deferred work is also of uncertain magnitude and timing. It can range from positive or negative magnitude and has volatile timing.
  3. There is also a highly uncertain future burden to repay the postponement of work – the amount and timing of this burden is unstable.

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.

First Calculation

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.

Second 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.

Third Calculation

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:

  • Using an economic frame that treats the decision to incur technical debt as an economic choice will help guide the process. Taking on technical debt should not be seen as a philosophical choice but as one that shrewdly weighs cost and benefit.
  • Focus on net benefits – sometimes leaving out a feature can cripple a system, and other parts of the system can begin to increase in cost. A close look at the work chosen to be deferred and how it will affect the rest of the system is necessary.
  • Feedback is staple in technical debt management, early on in a project it can significantly help reduce risk. Risk reduction can often become more important to consider than savings or expenses.
  • There is a common tendency to overestimate the benefit or releasing debt free product. This solution always seems like the better option when it is not being executed, but when practiced it can be different. Going through with analysis of the options ensures that a discount value be placed on the debt free solution.
  • Recognize the dependency on time that the economic rent associated with postponed work entails. For example, there is a targeted 30% performance advantage in a project – but earlier on in the life cycle it is possible to attain a 20% performance edge. It could be economically beneficial to take a hold of the 20% advantage and then move on to achieve the original 30% goal before competitors reach parity. The period of time when there is a sufficient performance advantage over competitors can be considered rent free.  Therefore exploiting that time to retire debt before interest charges set in can be a good strategy.
  • Consider that there are situations where there may not be rent on deferring work: when nobody cares about a feature there is no value in delivering it early, and no cost when it is not available.
  • Acknowledge the times when rent can be negative; this is when the feature being left out may actually cost more than the benefit received by it. For example, deciding whether to use a piece of open source software immediately vs. developing a superior solution by using customized code. The open source option may produce less utility than a customized solution, but it may save significantly on support costs. Therefore, when savings on support exceed the forfeited utility, deferring work and opting for open source produces negative rent.
  • Evaluate the need to repay the principal carefully – often times it will be cheaper to pay in the future because requirements will be better defined. However, there are instances where the cost increases drastically the more time is spent waiting to pay the principal back.
  • Don’t assume that doing work immediately will prevent work from having to be done later. There may be a scenario where the preemptive effort did not prevent further effort, and the work is paid for twice.
  • Reduction in batch size improves the economics of deferral. For example, if 50% of the work is postponed for a later date and the other 50% is delivered, the cost of deferral will be high.
  • Be aware of the biases that arise when referring to deferred work as technical debt – technical debt as a term often causes the costs of deferral to be overestimated because of the negative connotations associated with debt. Calling it a deferral instead of debt increases the relation of the metaphor to finance, because it is a term that is also used in the industry and is devoid of a positive or negative connotation.

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|