Everyone talks about technical debt like the national debt. It’s bad and needs to be paid back. But, just like financial debt, technical debt needs to be examined to see if it’s better to pay it off or just pay interest. That’s what our federal government is banking on, low interest rates!
Before we get into technical debt management, let’s take a look at what it is first. Developers can implement functions sometimes hastily while thinking of just that particular feature which could possibly result in:
- Difficulty integrating well with other features
- Difficulty making changes to that code to supplement the feature
- Difficulty for others to understand the code
There is usually a cleaner solution or method that takes longer to code, but makes changes easier and circumvents or minimizes the problems above.
Sloppy code could work perfectly in the first release and satisfy the immediate requirement, but if done continually it will lead to inflexible software that can’t be easily maintained or modified for new requirements. Some typical examples of technical debt include:
- Fixes that didn’t get done
- Refactoring that needs to be done
- Architectural changes that need to be done
The cost of the debt, like interest for a mortgage, is the extra work (or interest) that you incur due to the debt. For instance, you made a poor architecture decision that causes you to take 20% longer to implement features. Then that is the interest you pay on the debt. In this example, suppose it should take you 100 hours, but instead takes you 120 hours.
In layman terms, having technical debt means that compromises and delayed work have been incurred in your project (usually to meet a release deadline). It’s unavoidable and the effort required to eliminate or reduce debt can only be truly measured after the fact.
Measuring technical debt is the amount of work needed to erase the debt. Unfortunately, its difficult to ascertain the amount of effort to reduce or eliminate the debt but as long as you use the same evaluation methods for effort estimation as the rest of your development estimates, then that will ensure consistent measures. Planning for the effort required to reduce technical debt should be included in the development plan as any work item in a sprint would.
Part of technical debt management is just like the government’s fiscal management; evaluating whether or not the debt should be paid. If the interest is low, why bother? In the previous example, let’s suppose the interest rate was 4% (like it is now for a 30 year mortgage). If you continue to pay 4% interest and you have a 1000 hour task, that’s 40 extra hours. But let’s suppose the estimate to eliminate the debt is 200 hours. What decision would you make? Operation Twist?