The topic of technical debt or the down-stream costs of careless development is one of the fastest-growing software measurements. However, as most widely calculated technical debt is alarmingly incomplete. Pre-release quality costs are usually omitted from technical debt calculations. Even worse, the very high costs of projects that are cancelled and never delivered have zero technical debt.
Historically the cost of finding and fixing bugs or defects is the largest single expense element in the history of software. Bug repairs start with requirements and continue through development. After release bug repairs and related customer support costs continue until the last user signs off.
Over a 25 year life expectancy of a large software system in the 10,000 function point size range almost 50 cents out of every dollar will go to finding and fixing bugs. Unfortunately technical debt covers only a small fraction of the true costs of poor quality.
The concept of technical debt is the newest of software quality metrics, having first been described by Ward Cunningham in a 1992 paper. From that point on the concept went viral and is now one of the most common quality metrics in the United States and indeed the world.
The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify.
As a metaphor or general concept the idea of technical debt is attractive and appealing. For one thing it makes software quality appear to take on some of the accumulated wisdom of financial operations, although the true financial understanding of the software industry is shockingly naive.
A major problem with technical debt is that it ignores pre-release defect repairs, which are the major cost driver of almost all software applications. Ignoring pre-release defect repairs is a serious deficiency of technical debt.
Second, what happens after software is released to the outside world is not identical to the way software is developed. You need to support released software with customer support personnel who can handle questions and bug reports. And you also need to have maintenance programmers standing by to fix bugs when they are reported.
This means that even software with zero defects and very happy customers will accumulate post-release maintenance costs that are not accounted for by technical debt. Let us assume you release a commercial software application of 1,000 function points or 50,000 lines of Java code.
Prior to release you have trained 2 customer support personnel who are under contract and you have 1 maintenance programmer on your staff assigned to the new application. Thus even with zero defects you will have post-release costs of perhaps $15,000 per month.
After several months you can reassign the maintenance programmer and cut back to 1 customer support person, but the fact remains is that even zero-defect software has post-release costs.
The third and most serious flaw with technical debt concerns the 50% failure rate of large systems in the range of 10,000 function points or 500,000 Java statements in size. If an application of this size is cancelled and not released at all, then technical debt will of course be zero. But a company could lose $25,000,000 on a project that was terminated due to poor quality!
Yet another omission from the calculations for technical debt are the costs of litigation and punitive damages that might occur if disgruntled clients sue a vendor for poor quality.
Here is an example from an actual case. The stock holders of a major software company sued company management for releasing software of such poor quality that the shareholders claimed that poor quality was lowering the stock price. Technical debt does not include legal fees and litigation costs.
Clearly the defects themselves would accumulate technical debt, but awards and punitive damages based on litigation are not included in technical debt calculations. In some cases litigation costs, fines, and awards to the plaintiff might be high enough to bankrupt a software company.
This kind of situation is not included in the normal calculations for technical debt, but it should be. In other words, if technical debt is going to become a serious concept as is financial debt, then it needs to encompass every form of debt and not just post-release code changes. Technical debt needs to encompass the high costs of cancelled projects and the even higher costs of losing major litigation for poor quality.
To illustrate that technical debt is only a partial measure of quality costs, table 1 compares technical debt with cost of quality (COQ). As can be seen, technical debt only encompasses about 13% of the total costs of eliminating defects.
Note also that while technical debt is shown in table 1 as $86,141 right above this cost are the much higher costs of $428,625 for pre-release quality and defect repairs. These pre-release costs are often excluded from technical debt!
Just below technical debt are costs of $138,833 for fixed overhead costs of having support and maintenance people available. These overhead costs will accrue whether maintenance and support personnel are dealing with customer calls, fixing bugs, or just waiting for something to happen. Even with zero-defect software with zero technical debt there will still be overhead costs. These overhead costs are not included in technical debt, but are included in cost of quality (COQ).
|Code defect potential||1,904|
|Req. & design def. pot.||1,869|
|Total Defect Potential||3,773|
|Per function point||3.77|
|POST-RELEASE REPAIRS (TECHNICAL DEBT)||$86,141|
|COST OF QUALITY (COQ)||$653,629|
|High severity %||18.94%|
Even worse, if a software application is cancelled before release due to poor quality it will have zero technical debt costs but a huge cost of quality.
An “average” project of 10,000 function points in size will cost about $20,000,000 to develop and about $5,000,000 to maintain for 5 years. About $3,000,000 of the maintenance costs will be technical debt. But if a project of the same size is cancelled, they are usually late and over budget at the point of termination, so they might cost $26,000,000 that is totally wasted as a result of poor quality. Yet technical debt would be zero since the application was never released.
The bottom line is that the use of technical debt is an embarrassing revelation that the software industry does not understand either basic economics or quality economics. Cost of quality (COQ) is a better tool for quality economic study than technical debt.
Technical debt has become a very popular topic in software quality circles. However as commonly calculated technical debt only covers about 13% of the true costs of poor quality. In order to evolve from a novelty into an effective metric, technical debt needs to encompass all quality costs and not just post-release code changes. In particular technical debt needs to recognize the high costs of projects terminated prior to release because of poor quality.
For more information on how this data was calculated, visit http://www.namcook.com
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.