Prioritizing technical debt
Tracking and communicating technical debt is a critical part of the process of paying it down. However, it’s just one step in the process.
While refactoring code as related code is modified can be a viable strategy for paying down technical debt, this approach isn’t suitable for tackling large pieces of technical debt or debt that is related to the overall design of the software.
In Chapter 17, Agile Refactoring, we’ll talk more about managing these larger pieces of work in an agile environment, but for now, let’s look at how you determine which pieces of technical debt should be prioritized.
You want to prioritize addressing the items that are most likely to occur and those that will hurt the most if they do occur. In other words, if you have a high probability risk, you should prioritize that. Additionally, you should prioritize your high-impact pieces of technical debt.
