The Financial Implications of Technical Debt

[quote style=”boxed”]”Technical Debt may be costing you more than you imagined!”[/quote]
There has been a great deal of discussion in the agile community about technical debt, much of it recently being led my colleague Israel Gat. The technical debt curve in the Figure shows how technical debt increases the cost of change over time, until software becomes almost un-maintainable. Two time scales can be shown on this curve, a longer term scale that shows how software degrades over time and severely impacts customer responsiveness, and a shorter term (by iteration) scale that shows how technical debt can seriously impact development speed very quickly.

One problem with technical debt is that the impact can be slow growing and somewhat hidden.  To the question “Fix the technical debt, or build new features” we know how it is usually answered. As it gets worse customers complain about slow delivery, increasing the pressure to take more short cuts, which increases the technical debt, which slows the delivery process, which increases customer dissatisfaction, in a rapidly spiraling vicious cycle. Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement.

Israel Gat has been working to identify the financial cost of technical debt by examining existing software and calculating the cost of fixing bad code. Recent studies have indicated this overall “hidden” cost of technical debt in the $1 trillion range in the US. But this is only the tip of the iceberg when looking at the total financial impact.

Looking at the Agile Triangle in the next Figure, we can envision that project value numbers (NPV or some such measure) eventually works its way into corporate earnings.  In software companies this would be a direct correlations since the value is contained in products themselves, in internal IT projects the correlation is a little fuzzier, but none-the-less valid. Quality has two components: reliability that is the ability of the software to operate as billed, and adaptability that is the ability to respond quickly to future enhancements. Using these definitions, technical debt can impact current value (earnings) if it doesn’t perform as it should, and it impacts future earnings by slowing down the delivery process.

Unfortunately, in many companies, driven by Wall Street’s emphasis on current earnings which then permeates the company, managers opt for delivering current features over reducing technical debt. So the financial impact of technical debt goes beyond the cost of fixing the debt, it also has a big impact on the ROI of any project because it delays benefits and costs more to implement.

So if those are future impacts how do we get financial managers, product managers, and others to focus on the present when it comes to reducing technical debt? And the answer is: Market Capitalization.

In the 4th quarter of 2000, a well-known technology company missed their Wall Street earnings prediction by a few cents per share and proceeded to lose $20+B in market capitalization in the next few days. The biggest problem with technical debt is not its impact on value or earnings, but its impact on predictability. Two companies with equal average earnings growth, but different earnings volatility, can have very different market capitalization driven by the volatility.

Everyone has horror stories of software applications that are virtually un-maintainable as change causes erratic behavior. These applications are terribly hard to test and are always buggy in production. Technical teams try to “plan” upgrades to these applications, but inevitably they miss projections, often by a lot. When the company is depending on new features to launch new product versions, delays impact earnings volatility. Getting back to the technical debt curve, as technical debt increases, development speed decreases, customer satisfaction decreases, and predictability of results decreases.

So the bottom line for technical debt. It’s expensive to fix, but much more expensive to ignore. Technical debt reduces future earnings, but even more critically, it destroys predictability which in turn impacts market capitalization in the near term, not in the future.


    1. Marty Nelson says

      I think in stating “technical debt increases the cost of change over time, until software becomes almost un-maintainable” people only hear the second part and think that the danger comes in some terminal endpoint. It is not always the case that the problem is compounded by “customers complain about slow delivery, increasing the pressure to take more short cuts”.

      More insidious are the years of slow productivity of (unnecessarily) costly features. Ironically, a team adopting Agile after the creation of the bulk of debt-ridden code can arrest the accumulation of debt and bring about predictability, while still being bound by a velocity of walking through the mud of technical debt.

    2. An alternative metaphor that works better in some circles is of bad code as an unhedged call option. It’s not perfect, but it does give a nice sense of how a codebase can suddenly become a liability when requirements change.