This is part of a series called Eight Questions to Ask About Your Tech Debt
- Introduction
- #1: Visibility, #2: Misalignment, #3: Size, #4: Difficulty, #5: Volatility, #6: Resistance, #7: Regressions, #8: Uncertainty
The main thing to keep in mind is this diagram (described in the introduction):
Now, I’ll show you how I use these questions. Let’s consider two tech debt backlog codebase problems (with codenames in bold):
- React Func: A React website that has 20% of its pages still using class components instead of functional components
- Mobile Port: A non-responsive website that needs to work on mobile devices
In each of these cases, not paying the tech debt means we’d make minimal changes and work-arounds whenever we needed to change the code to implement the roadmap. Paying the debt means some kind of code migration to get the code to be whatever it would be if we were starting now knowing how the code will be used.
Use the questions as a way to drive the discussion. Resolve disagreements on the team to come to a consensus on each score. It’s similar to how you might play the planning game with story points.
For each question, here’s a score from 0 to 5, where 0 means that this code doesn’t have this driver and 5 means that the driver has a big effect on this debt project. You might disagree with how I score it—that’s normal.
#1: Visibility: If this debt were paid, how visible would it be outside of engineering?
- React Func: 0 – If done right, no one would even notice
- Mobile Port: 5 – A large percentage of our customers want this and would value it
#2: Misalignment: If this debt were paid, how much more would our code match our engineering values?
- React Func: 4 – All new code uses functional components and our style guide requires it
- Mobile Port: 0 – Scored low because there is no engineering agreement to code this way, yet.
#3. Size: If we knew exactly what to do and there were no coding unknowns at all, how long would the tech debt fix take?
- React Func: 3 – This depends on the number of components in the system. In this case, we think it would take a few weeks.
- Mobile Port: 5 – Major change in the codebase – multiple months
#4. Difficulty: What is the risk that work on the debt takes longer than represented in the Size score because we won’t know how to do it?
- React Func: 0 – This is fairly mechanical and might be able to be automated (or AI assisted). We have tests in place.
- Mobile Port: 3 – We are not sure how to do it yet.
#5. Volatility: How likely is the code to need changes in the near future because of new planned features or high-priority bugs?
- React Func: 2 – We change this code sometimes, but they haven’t been converted because they don’t change much
- Mobile Port: 5 – The roadmap requires we change this code soon
#6. Resistance: How hard is it to change this code if we don’t pay the debt?
- React Func: 2 – It’s not ideal, but the team knows how to do it. As time goes by, it gets worse (Junior devs might not know it)
- Mobile Port: 5 – The code does not support our required roadmap plans
#7. Regression: How bad would it be if we introduced new bugs in this code when we try to fix its tech debt?
- React Func: 4 – The code works and customers rely on it
- Mobile Port: 5 – The code works (on desktop) and it’s the whole site
#8. Uncertainty: How sure are we that our tech debt fix will deliver the developer productivity benefits we expect?
- React Func: 0 – We are sure that what will do will be easier to work with
- Mobile Port: 2 – There are a few ways to do this. We don’t know the right way yet.
I use this spreadsheet to get a net payment force:
https://docs.google.com/spreadsheets/d/1eAaGpiBQYJrQTiVPp8mdSvll-g75LT1UzKmbbufqWxA/edit?usp=sharing
When I plug the numbers in, I get a net force of 0 for “React Func” and 0.27 for “Mobile Port”. These scores are normalized on a scale of 0-5, so in both cases, these might be considered the most important. But, they are not negative. In the “Mobile Port” case, we know that the Roadmap is requiring us to do something about it, but it would be good to reduce the Stay Forces.