by Arlene Minkiewicz
| September 24, 2014
Here’s an interesting article “Technical Debt as Metaphor for Future Cost” (). In this the author discusses the acceptability of using the metaphor of technical debt to facilitate communications between business leaders and the software team when negotiating around the triangle (time, money, scope). And while the author accepts the use of this metaphor good “short-hand” for communicating the fact that avoiding the work now is not sparing the cost but just rearranging the way the costs are incurred – and often increasing the overall costs that need to be spent.
The caution this article carries about the use of this metaphor is not around the realization that decisions made to shortcut the process or defer functionality will cost in the future, but rather around quantification of how much they will cost in the future. When we incur financial debt we basically know what we owe – within some uncertainty about future economic conditions. But as the author points out in order for technical debt to successfully facilitate conversations with the business there needs to be trust established about the software team’s ability to quantify the magnitude of the debt.
So how do software teams gain this trust and create successful negotiations around software project decisions. First of all they need a good language around which to have the conversation. Using source lines of code or function points as a basis for describing the size of the debt is a good start. An even better measure would be software size augmented by factors that indicate innate complexity and quality level (each of these is basically unit-less in the large but can be unitized within an organization) Good historical data is a great place to start understanding how size, complexity, quality all contribute to technical debt. Teams that have shown successes through success software estimation are the teams who the business will listen to when the suggest that this shortcut will create this X hours of additional work effort in a future release or that the additional overhead associated with not fixing this problem now will be Y hours.
How does your organization go about quantifying technical debt?