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 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?
Difficulty is about risk and the error bar to your size estimate. It is another cost of paying that contributes to the Stay Force.
If we’re dealing with messy code that could use some refactoring, tests, and documentation, then it’s relatively easy to make those changes without introducing bugs. In that case, I would score Difficulty low. But if our plan requires a total rewrite, then the difficulty is higher because there are things we might not know until we start.
All of this assumes you can come up with a potential solution. If you don’t even have a plan to pay down the debt, then the default difficulty score should be high.
If Difficulty is High, Try a Project Spike
If the Difficulty score is high, then a good strategy is to get a more sure estimate of Size by doing a project spike (also called a pilot project or a proof-of-concept). The goal is to make the estimate more accurate and to address the risks. After doing it, your size may change (up or down), but more importantly, the Difficultyscore will reduce as you are more sure of the size.
Chapter 12 covers this strategy. You can read it here: https://helpthisbook.com/lou-franco/swimming-in-tech-debt
Next: #5 Volatility