Technical Debt

Technical debt refers to the implied cost of future refactoring or rework to improve the quality of an asset to make it easy to maintain and extend. When we have significant technical debt it becomes difficult to predict how much effort work will be—working with high-quality assets is much easier than working with low-quality assets. Because most technical debt is hidden (we don’t really know what invokes that source code we’re just about to change or we don’t know what’s really behind that wall we’re about to pull down as we renovate our kitchen), it often presents us with unpredictable surprises when we get into the work.

Ideally, we shouldn’t make our organization’s technical debt problem any worse than it already is. By being quality focused, by quickly addressing any quality problems that we do inject into our work (often via refactoring), we can avoid adding new technical debt. We should also remove, or pay down, existing technical debt when we run into it.  By cleaning up existing technical debt a bit at a time, we spread out the cost of doing so. Techniques for doing so are captured by the Improve Quality process goal.

Sadly, it isn’t always an ideal world and we sometimes find that we need to accept technical debt. This should be done explicitly by the team in a deliberate and prudent manner. This is a decision that should be led by the architecture owner and confirmed by the product owner. Figure 1 summarizes Martin Fowler’s Technical Debt Quadrant, which explores the types of reasons for why technical debt is injected into your work. Note that a project management decision to hit a date that doesn’t take the impact on technical debt into account would land in the deliberate and reckless quadrant, not the deliberate and prudent quadrant.