Time to Start Estimating Technical Debt
ByOn October 29, 2012 At 2:31 pm
Responses : No Comments
Last week IEEE Software published a special edition for their Nov/Dec issue, dedicated to Technical Debt! My colleagues and I at CAST Research Labs put together an article which was featured in the magazine on how to quantify and measure the concept. What resonates in this paper is the adjustable formula that can be used by IT executives to quantify the technical debt principal within their critical business applications.
This paper is available to be purchased here but thought it would be a good idea to give a quick outline of what is presented:
The Technical Debt Metaphor
Steve McConnell defines technical debt as both the intentional and un-intentional violations of good architectural and coding practices (a broader approach to Cunningham’s original definition from 1992). The metaphor is made up of two essential components: principal and interest.
- Principal is the cost of remediating must-fix problems in production code. This is a fixed amount of debt that has been borrowed when the decision to take a shortcut originally took place. It is the minimum amount that needs to be paid back.
- Interest is the continuing cost, primarily in IT, attributable to must-fix problems in production code, added on to the technical debt principal.
Leaning on this approach, we define Technical Debt as “the future costs attributable to know violations in production that should be fixed – a cost that includes both interest and principal”.
Quantifying Technical Debt Principal
The real issue with the technical debt metaphor is that it can appear to be very abstract. In order for IT executives to be able to realistically manage it, the concept needs to become measurable. The paper introduces a simple formula that can be used to do exactly this.
Focusing on the minimum amount of debt that should be paid back in an application (i.e. the principal) we can estimate the amount as a function of three variables:
- The number of should-fix violations – which can be detected by static code analysis tools
- The hours to fix each violation – adjustable variable available from historical effort data
- The cost of labor – adjustable variable set as the average burdened rate for the developer assigned to the activity.
The above formula was first presented in the 2012 CRASH Report (CAST report on Application Software Health – more information here), based on a repository of 700 applications submitted by 158 organizations and representing more than 357 MLOC – the first and largest sample of applications to be analyzed for structural quality – which have been run through the static analysis platform called CAST.
This technical debt estimation had estimated an average of $3.61 of technical debt per LOC within a typical application. After breaking-down the data into technology groups, it reported that Java-EE had the highest Technical Debt scores, averaging $5.42 per LOC; whereas COBOL and ABAP/SAP had some of the lowest Technical Debt scores.
This paper however takes this former research to the next level, presenting 3 different settings for the Technical Debt parameters to provide managers with ballpark figures for assessing future maintenance costs, and make investment decisions regarding structural quality improvements. The analysis also digs deeper into the types of violations that create technical debt principal, presenting the most frequent violations per technology stack: a powerful tool to aid management in understanding and controlling IT costs and risks.
Purchase the IEEE paper here.