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 Regressions: How bad would it be if we introduced new bugs in this code when we try to fix its tech debt?
If it Ain’t Broke …
If your code implements a part of your product that is heavily used and depended upon, then any change to it risks adding new bugs. We call this kind of bug a regression. Leaving working code alone is a benefit of not paying tech debt. It’s a force that pulls us back from fixing debt in it.
If you need to add features to this code, then the future volatility will be high, which indicates that tech debt should be addressed. But volatility makes a high risk of regression worse. If your users are highly dependent on a set of features to work correctly, then fixing tech debt might break something, causing a regression. It’s a tradeoff you need to resolve.
The risk of regression in a system is correlated to how many users depend on it. You can assess this with usage analytics, but it may be obvious if the code runs a core part of your offerings. If they are fundamental in your sales pitches, webinars, or highly promoted on your website, that’s strong evidence that any regressions would be noticed and meaningful.
If The Risk of Regressions of High, Start By Mitigating Them
When I am paying tech debt in important code, I start by making sure I will know if anything goes wrong. I start with unit tests and then also add observability. I talked about adding Observability in beginning of Chapter 9 (free at HelpThisBook). While you are there, check out Chapter 5 which is my strategy for removing tech debt without causing regressions (concentrating on Liskov-like Substitutability).
For the most important code, I plan to run the new and old versions in parallel. Apple did this with APFS (their update to the iPhone filesystem) by doing test migrations well before release. I did this in a project I cover in chapter 30 (a two-year rewrite). You can see a version of that chapter (from a year ago) in section 7 of my guest article on the Pragmatic Engineer newsletter (Gergely graciously took off the paywall for this article in celebration of the book’s launch). I would also recommend reading his article: Migrations Done Well, which explores that concept in depth.
As a counter-example, if there’s no chance of regression because no one is using the feature, fix its debt by deleting the code (with permission, of course).
Next: #8 Uncertainty