This is part of a series called Eight Questions to Ask About Your Tech Debt
The main thing to keep in mind is this diagram (described in the introduction):
The next question we’ll cover is on Volatility: How likely is the code to need changes in the near future because of new planned features or high-priority bugs?
Volatility captures how much the code will likely change because it needs new features or has high-priority bugs. We’ll have more encounters with this code. If you have high volatility, then you are constantly making interest payments on your debt. It’s a force that pushes us to pay it.
When scoring volatility, we care most about short-term future changes. We can estimate that in two ways. The first way is to assume that your short-term future volatility is correlated with your recent past. Your repository history can be used to estimate that.
The second way to predict future volatility is to use your roadmap for the next two quarters. Look at it when you are sorting and scoring volatility. Consider if this debt is going to be encountered soon.
Completely Rethinking Something is Low Volatility (to the existing code)
Consider a website with a four-page flow that implements some process. Let’s assume that that code is horrible and hard to change. Now, let’s say our PM has some new idea about this process and there is now a plan in the next quarter to completely replace this area with a totally new flow, new forms, new process, etc that is simpler than what we have?
Should that plan be used as a reason to fix the messiness in the code we have? Of course not.
If we plan to “change” code by completely throwing it away, then that code has low Volatility. To be clear, I am talking about a PM-led reason to delete functionality, or a rewrite that fixes business problems like performance or security. If that is going to happen, then don’t try to improve this code in the short-term because it’s going away.
Next: #6 Resistance