Paying down tech debt
Paying down tech debt
Struggling to find your "tech debt balance?" Here's an effective formula that ensures you'll get tangible value in exchange for your effort.
It’s hard to know how to tackle tech debt, especially on a large project. Should you invest the time to reduce debt? Ignore it and push forward with new features? Resign yourself to living with an ugly, hard-to-use code base?
Connect to productivity and value
There’s actually a really good algorithm to answer these questions. It’s rooted in tying your tech debt remediation to delivering value, as Lou Franco points out:
The heuristic I use to pay tech debt these days is this: by reducing a specific tech debt, can I increase developer productivity and deliver business value right now?
If I can’t, then I don’t pay it down.
The results can’t be argued with. You get faster feedback loops, less cognitive load, and happier, more productive developers — which all leads to getting valuable features out the door faster.
’s recent guest post, on The Pragmatic Engineer, about paying down tech debt is excellent. I highly recommend the read, he gives some fantastic advice and real-world situations to build on. It’s a strategic article on pragmatically tackling tech debt.1Increasing developer productivity and business value is key. But, it can be a challenge making that connection. So how do we “find the value?”
Finding the value
One technique that works very well in bridging that gap is conducting a waste walk, something I’ve written about (the details are in part 2 of that article). Waste walks were born out of Lean 6 practices a long time ago — the gist is pretty simple. We just bucket our work into value add and non-value add activity. It takes almost no time (a few minutes a day).
What’s great about a waste walk in this context is that it exposes where the team’s productivity is being hurt, and most of the time the greatest burden is tech debt. Time spent on rework, struggling with build processes, and fixing legacy code gets quantified. It makes the cost of tech debt tangible.
In one waste walk I participated in, we found that out of 275 hours of work invested, only 37.75 hours of work actually went in refining new features!
As the waste walk exercise exposed (above), most of the team’s time went into rework and unplanned meetings. Most of those unplanned meetings focused on solving the challenges related to rework. The bottom line was that the team spent about 86% of their effort just struggling to keep things operational.
With that kind of evidence in hand, it’s usually an easy choice to improve the situation.
If you’re interested in learning how to integrate techniques like waste walks and Value Stream Engineering into your own pipeline, take a look at my Delivery Playbook. It focuses on maximizing value delivered.
If you find Customer Obsessed Engineering and the Delivery Playbook valuable, please share it with your friends and coworkers.
Special thanks to Lou Franco and
for their excellent article on paying down tech debt.Lou Franco, Paying down tech debt, The Pragmatic Engineer, Sep. 3, 2024.