Are you convinced your team should spend time paying off technical debt, but you can’t get upper management on board? Here are some ideas that might help.
Collect Numbers
Upper management or the board of directors work a lot with numbers. Their job isn’t always easy: the people they manage are most often not happy with the resources they get. They usually want more so that they can achieve more.
But C-level managers need to take all groups, interests, budgets and future plans into account. So when you think they’re taking a bad decision for not paying technical debt, they see the current solution still working and making money. They see that the new features are more important than reworking the existing features just because some developer said it would be better.
You need to convince them that refactoring has business value. If not, then why even bother?
You might be able to convince them by explaining the security implications of technical debt. Or that it’s increasingly hard to find and keep new developers (because they leave disillusioned).
But nothing works like real numbers.
Here are two numbers that are interesting to keep track of:
- disaster-release-ratio
- time wasted on technical debt
Disaster-Release Ratio
I’m not aware if there is any other name for this metric, but the idea is that you track the number of showstopper bugs per release.
Update: apparently, there is a metric called Change Failure Rate that is basically what I describe here.
I focus on showstopper bugs (or “disasters”) because you might have minor bugs that don’t warrant urgent intervention. If a developer can take their time to fix it and it can be deployed in the next release, I don’t consider it for this metric.
But if the bug requires a bugfix to be deployed or worse, a rollback of the release to the previous version, then I count it in the metric.
Once you have that, you can group them per release for a given time period (e.g. the last 6 months) and get the result as an average over several releases:
DRR = number of disasters / number of releases
You want this number to be as close as possible to zero. If it’s approaching 1, then you’re having a critical bug (almost) on every release. If it’s greater than 1, then the situation is very bad.
Because this is a simple calculation with two inputs, you can improve the situation by changing one of the two numbers.
Either you decrease the number of bugs by paying off technical debt and increasing automated testing.
Or you increase the number of releases. This will also take the number down. This may sound counter-intuitive, but I’ve previously covered on why this actually works.
Time Wasted on Technical Debt
Developers often complain about how much time they waste on technical debt and legacy code. Maybe you understand their pain but upper management doesn’t. After all, most of the time they have no experience with code.
Here’s an interesting technique I learned from Mathias Verraes. He calls it the Wall of Technical Debt. Be sure to read his post, but the core idea is simple:
- Developers identify key areas where they lose a lot of time (and where they feel this shouldn’t be the case)
- Each of these area’s is written down on a post-it and put up on the wall
- Every time a developer has to work in such an area and loses time, they add dots to the post-it (e.g. one dot per half day) for the time they could have spent on something else
This will visualize how much time is lost on technical debt. If you combine this with estimations on how long it would take to fix an area of technical debt, you’ll have some crude numbers to show upper management.
If developers have lost a total of 10 working days for something they estimate would take 4 days to fix, maybe it starts making business sense to fix it?
On the other hand, you might gain insights into which pieces aren’t worth fixing, which is also useful.
Talk With Management
With these numbers in hand, you have something more tangible for them to talk about.
There are two things to note here.
First, if you succeed in creating a sense of urgency, don’t make them panic. This could lead to the “rebuild-trap” where people start thinking all is lost and they need to rebuild the entire application from scratch. Refactoring is usually the better option.
Second, understand that there are lots of other interests at play and that the product probably needs new features as well. Create a plan to slowly turn things around, identifying areas you want to tackle first and explaining how you want to tackle them. Assure them that you don’t want to stop all development for some lengthy refactoring effort, but that you prefer to chip away at the debt one bit at a time.
This should give you at least a better chance of convincing upper management that there is technical debt, it’s a problem, but it’s a problem that can be fixed.