Eight Questions to Ask About Your Tech Debt

In my book, Swimming in Tech Debt, I show this diagram:

This diagram shows how the costs and benefits of paying or not paying (i.e. staying with) tech debt help you make decisions about what to do.

I am going into detail on this in my e-mail list (join here) and there’s even more detail in the book (available for $0.99 until it launches.)

But, here are the questions:

1. Visibility: If this debt were paid, how visible would it be outside of engineering?

2. Misalignment: If this debt were paid, how much more would our code match our engineering values?

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?

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?

5. Volatility: How likely is the code to need changes in the near future because of new planned features or high-priority bugs?

6. Resistance: How hard is it to change this code if we don’t pay the debt?

7. Regression: How bad would it be if we introduced new bugs in this code when we try to fix its tech debt?

8. Uncertainty: How sure are we that our tech debt fix will deliver the developer productivity benefits we expect?

In the book, I ask you to score each tech debt problem a scale of 0-5 (0 being that is has none of this factor, 5 being that it is driven by this factor). I use these scores to decide what to do. I share a spreadsheet that shows you how.