Don’t Dawdle on Debt: Establishing a Technical Debt Action Plan

Posted By Jonathan Bloom on February 25, 2011 | Software Quality, Technical Debt

Recently, Gartner Analyst Andy Kyte made quite a stir when he published a report that brought to the forefront just how expensive the cost of software maintenance is becoming for the IT industry.  As reported by Patrick Thibodeau in Computerworld, Kyte cited what he called IT Debt as already standing at $500 billion and fast on its way to surpassing $1 Trillion globally.

More recently, the reason why these numbers are growing exponentially was pointed out in a TechRepublic blog by Chip Camden who said, “Some organizations treat Technical Debt similarly to how some governments and individuals treat fiscal debt: they ignore it and just keep borrowing and spending. In terms of Technical Debt, that means ignoring the mistakes of the past and continuing to patch new solutions over old problems.”

But why would anybody ignore something that puts their business at risk?

What is Technical Debt?

There are many ways to define and calculate Technical Debt.  When we conducted our APPMARQ study early last year, we defined it as the cost to fix the structural quality problems in an application that, if left unfixed, put the business at serious risk.  We stress serious because we didn’t include all problems in the calculation of Technical Debt, only those application structural quality problems that are highly likely to cause business disruption. We did find that the average application in a Global 200 company has more than $1 million in Technical Debt.  Even a small number of critical applications add up quickly to staggering hidden costs.

So to answer the question of why a company would ignore Technical Debt, the answer is “they shouldn’t!” What they should do is set a Technical Debt threshold to determine how much is too much, and then remediate the rest.

Setting a Technical Debt Threshold

When it comes to Technical Debt, a company needs to determine how much, if anything it should put into remediating it.

This is what Technical Debt does – it puts a monetary figure on application structural quality and enables comparisons that were not possible before between IT costs and potential losses due to failure.  The goal is to keep the number of structural quality violations – or more importantly, the cost to fix them – well below the cost the company would incur should they be deployed and a failure ensued.

A Technical Debt Action Plan

We recommend that CIOs and heads of applications use an automated system like CAST’s Application Intelligence Platform to evaluate the structural quality of their five most mission-critical applications. As each of these applications is being built, measure its structural quality at every major release. When the applications are in operation, measure their structural quality every quarter.

In particular, keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the Technical Debt of the application after each quality assessment. Once you have a dollar figure on Technical Debt, compare it to the business value to determine how much Technical Debt is too much and how much is acceptable based on the marginal return on business value (see graphic depiction below). For a framework for calculating the loss of business value due to structural quality violations, we recommend, “The Business Value of Application Internal Quality” by Dr. Bill Curtis.

Tags: Appmarq, CAST, Gartner, Project Management, Software, Software Development, software performance testing, Software Quality, structural quality, Technical debt