Is it worth paying down that tech debt?
A couple of weeks back, we took a look at how estimating the cost of delay of each proposed feature or change to a product can be used to assess different kinds of changes on equal terms.
The example I gave was extremely simple. Comparing three small feature additions can be relatively straightforward. Simple assessments of value can be achieved for changes that can be directly linked to measured outcomes. For example, improvements to the user acquisition funnel or swapping out a third party email service for a cheaper equivalent.
But most of the scope of product development (not to mention overall service delivery) is so much broader and more nebulous.
Unfortunately, it’s important but not necessarily urgent changes that often prove to be the hardest to estimate in terms of value. If you’ve ever tried to make a case for removing under-used features, making design improvements, paying down tech debt, rewriting inefficient code or improving performance, you know what I mean.
We’re often met with responses like “I agree we need to do that but it’s not the most important thing right now as we’ve got to keep [big customer or partner] on board by building [thing they want].”
And then when that’s done, we may try again, only to be knocked back again by some other Priority One must-have.
It can be hard to make the case for a longer-term viewpoint. My early efforts pushing for long-term technical change often met with failure because I was trying to appeal to the long-term benefits.
But using cost of delay allows you to compare the relative benefit of short and long-term improvements. And it also sounds so much more immediate.
Let’s take another look at our feature examples from last time, but we now have another option: paying down some tech debt first.
Let’s assume that the tech debt improvement work is not major, but is in the part of the system that we’re planning on adding more features to. The team has estimated that the tech debt work will take 3 weeks to complete, but completing it will make delivering subsequent features approximately 20% quicker.
Let’s see what impact doing this work will have on the overall cost of delay.
Remember:
- value is in Guatemalan Quetzals (Q)
- CD3 = Cost of delay / duration / 1000
Here’s the cost of delay, ordering features by CD3, which we discovered was the most efficient approach:
| Feature | Dev time | Value to business | CD3 | Cost |
|---|---|---|---|---|
| A | 2 weeks | Q5,000 | 2.5 | 2 * Q5k = Q10k |
| C | 1 week | Q2,000 | 2 | (1 + 2) * Q2k = Q6k |
| B | 6 weeks | Q10,000 | 1.7 | (6 + 1 + 2) * Q10k = Q90k |
| Total | 9 weeks | Q19,000 | - | Q106,000 |
And here’s the same calculation with the tech debt work performed before moving on to features:
| Feature | Dev time | Adj dev time | Value to business | CD3 | Cost |
|---|---|---|---|---|---|
| (TD) | 3 wk | 3 wk | Q0 | 0 | 0 |
| A | 2 wk | 1.6 wk | Q5,000 | 2.5 | (3 + 1.6) * Q5k = Q23k |
| C | 1 wk | 0.8 wk | Q2,000 | 2 | (3 + 1.6 + 0.8) * Q2k = Q10.8k |
| B | 6 wk | 4.8 wk | Q10,000 | 1.7 | (3 + 1.6 + 0.8 + 4.8) * Q10k = Q102k |
| Total | 12 wk | 10.2 wk | Q19,000 | - | Q135,800 |
Oh dear! Our overall cost of delay is 28% higher if we do the tech debt work first!
In this case, if we could be sure that these are the only three features we are going to add in that part of the product, we probably shouldn’t bother with the tech debt improvements if the only benefit of them is to make development work more efficient.
But if you’re planning a whole programme of work lasting more than 9 weeks, with extensive business value, the picture starts to change. Let’s add a complicated, high-value feature (feature D) to the mix.
First, without doing the tech debt work:
| Feature | Dev time | Value to business | CD3 | Cost |
|---|---|---|---|---|
| D | 16 weeks | Q48,000 | 3 | 16 * Q48k = Q768,000k |
| A | 2 weeks | Q5,000 | 2.5 | (16 + 2) * Q5k = Q90k |
| C | 1 week | Q2,000 | 2 | (16 + 1 + 2) * Q2k = Q38k |
| B | 6 weeks | Q10,000 | 1.7 | (16 + 6 + 1 + 2) * Q10k = Q250k |
| Total | 26 weeks | Q65,000 | - | Q1,146,000 |
Even doing the new feature first (because it has the highest CD3 value), we can see the massive impact it has on overall cost of delay!
And now with the tech debt work up front:
| Feature | Dev time | Adj time | Value to business | CD3 | Cost |
|---|---|---|---|---|---|
| (TD) | 3 wk | 3 wk | Q0 | 0 | 0 |
| D | 16 wk | 12.8 wk | Q48,000 | 3 | (3 + 12.8) * Q48k = Q758.4k |
| A | 2 wk | 1.6 wk | Q5,000 | 2.5 | (3 + 12.8 + 1.6) * Q5k = Q87k |
| C | 1 wk | 0.8 wk | Q2,000 | 2 | (3 + 12.8 + 1.6) * Q2k = Q50.6k |
| B | 6 wk | 4.8 wk | Q10,000 | 1.7 | (3 + 12.8 + 1.6 + 4.8) * Q10k = Q222k |
| Total | 28 wk | 23 wk | Q65,000 | - | Q1,118,000 |
That’s a pretty marginal difference, but it’s now more efficient to do the tech debt work first - just.
Note that the value to the business of the tech debt work is set at zero. That’s just the immediate value of doing the work. If the benefit of completing it is mostly one of development efficiency, it has latent value that converts to real value as more development work is done that benefits from it. In this case, the difference between the two final cost of delay values: Q1,146k - Q1,118k = Q28k.
Looking at this, it should not be hard to see how even a 20% improvement can pay dividends if we’re planning an extensive programme of work on this part of the product. But how quickly it does so is down to the value of the subsequent work to the business and not just how long it takes developers to create features.
This approach is not limited to tech debt. Any other work that might impact the team’s future ability to drive through value can be assessed in the same way. For example: building a component library, making improvements to test and release pipelines or adding a new team member. If those changes don’t go to plan, you can also see how it negatively impacts the cost of delay…
The figures I’ve presented here are hypothetical. In reality, you’re looking for unequivocal evidence one way or the other, because of all the assumptions baked into the estimates of value and time. If your estimates produce a marginal difference like the example above, you should probably make decisions based on more pragmatic concerns.
Next time we’ll look at some examples of these pragmatic concerns and how they can make a mockery of cost of delay estimates like those above.
Are you weighing up the possible benefits of some long-term improvement work? Why not try doing a napkin calculation like the one above to get a feel for the cost of delay? If you do this, I’d love to hear about it.
All the best,
– Jim
