It seems that there is a re-emergence of interest in software quality economics, especially as regards to what I termed the Cost of Software Quality [Krasner, 1998] which is a major component of the total cost of ownership of a piece of software.
The hot new term is “technical debt”, which was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a development approach or delivery schedule that’s expedient in the short term but that skips important steps, increases product complexity, decreases quality and is more costly in the long term. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. Determining which is which is problematic when technical debt is unseen until its too late. The ability to take on debt safely, track debt, manage debt, and pay down the debt varies among different organizations.
Steve McConnell points out that there are 2 types of technical debt to consider. The first type is incurred unintentionally (e.g. code defects) and likely unknowingly. The second type is incurred intentionally (e.g. release it NOW, to gain market share). In the analogy, the main question becomes how long can one put off paying down the debt, and what is the burden of carrying it. Once a debt is incurred there will be interest charges (debt service). If the debt gets big enough, all company work will go into servicing the debt rather than other more productive activities (e.g. fixing all the bugs after premature release to make the product usable). Not all delayed work is technical debt – e.g. feature backlog, deferred features, cut features, and so on. These aren’t debt, because they don’t require interest payments.
Like financial debt, different companies have different philosophies about the usefulness of debt. Some companies want to avoid taking on any debt at all; others see debt as a useful tool and just want to know how to manage debt wisely. In any case, the strategy is to make the debts explicit and trackable in the “debt tracking system”. This is done just like problem and defect tracking. A good approach to working down the debt is to take a specified development iteration and devote that to paying off high valued technical debt items, or carve out a small percentage of an iteration and devote that to retiring debt items (kinda like a minimum monthly payment). The more debt a project accumulates, the more a project’s rate of progress (i.e., velocity) will slow down. The goal is to keep the debt service at a reasonable level compared to a company’s other expenses and investments.
According to the the CRASH Report for the year 2011 the technical debt of the CAST Appmarq benchmarking repository shows an Average of $3.61 of Technical Debt per LOC, up from $2.82 the year before. They state that the cost of fixing Technical Debt is a primary contributor to an application’s cost of ownership, and a significant driver of the high cost of IT. http://www.castsoftware.com/products/appmarq
According to Capers Jones, technical debt only covers about 13% of the true costs of (software) quality, and it ignores canceled projects that are not even delivered. He claims therefore that technical debt is not suitable for economic analysis.
Will technical debt catch on, or is it just another fad to try and get executives’ attention in order to communicate the essential value of software decisions made over its useful lifetime. Is technical debt just an agilist view of cost of quality? I am betting that lots of papers will get written over the next few years on the topic, but how much useful data will be produced I do not know ?
What’s your opinion??? Have you experienced a discussion of technical debt in your organization??? If so, how would you describe that discussion?