In software development, much like in life, a little debt can actually be a good thing to get other more critical things moving. Although in previous blogs we have defined technical debt as “the cost to fix structural quality problems in an application that, if left unfixed, could put the business at risk,” engaging in a small, manageable amount of technical debt can actually make a project move faster and facilitate reaching the objective of executable application software. This was the thought of Ward Cunningham, the originator of the technical debt concept.
But as Derek Huether points out in his technology consulting blog for Dumas Lab regarding technical debt, “Just like regular debt, you’re going to have to pay it back sooner or later. “
Huether also notes that much like the debt in our personal lives, if not paid back somehow:
…it will come back to haunt you. If your kludge of a solution doesn’t come back to bite the development team, it will probably haunt the help desk, support team, or someone else downstream.
He then adds:
Just like regular debt, you’re going to have to pay it back sooner or later…, I’ve seen (and see) what technical debt can do to the velocity of a team. It robs them of precious time, after the fact. The development team buys into the idea that doing things the wrong way, to save some time in the interim, is worth the risks and the overall cost. This is a really short-sided [sic] thought process. Technical debt is like getting a loan from loan shark who roles dice to decide what your interest rate is. So, if you don’t need to take the risk, don’t do it.
But is technical debt really and “all or nothing” proposition?
How Much is Enough?
When it comes to Technical Debt, a company needs to determine how much, if anything it should put into remediating it. The best way to do this is by monetizing technical debt to put a financial figure on application structural quality. This allows for comparisons between IT costs and potential losses due to failure that were previously not possible.
The goal of monetizing technical debt 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 if application software were to be deployed and a failure ensued.
A Technical Debt Action Plan
In order to determine the tipping point of structural quality issues and the cost to fix them, a company should utilize a platform of automated analysis and measurement to evaluate the structural quality of their five most mission-critical applications. As each of these applications is built, its structural quality should be measured at every major release and once they are in operation, the structural quality of the application should be measured every quarter.
The key is to 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. When a dollar figure for technical debt has been ascertained, it can be compared 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. 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.
Once that tipping point is determined, a company can decide where and when it needs to address the issues of structural quality that created the technical debt.
The nice part about unloading technical debt is that like personal debt, it saves a ton on interest payments, yet there’s no penalty for paying it off early…in fact, it yields a significant reward of higher quality software.