We should make a distinction between Managed and Unmanaged Technical Debt.
By
Mathias Verraes
Published on 21 July 2013
Update 2020-01-22 I wrote a new version of this.
Alberto Brandolini said at IDDD Belgium (quoting from memory):
We've always explained 'technical debt' badly to the business. If you have debt with a bank, you can talk to someone, negotiate, and agree on a payment plan. But technical debt is like debt with the mob: they come at night, pointing a gun to your head, and they want their money NOW.
Greg Young on the other hand, has talked on several occasions about how technical debt is not necessarily bad. Businesses take loans all the time. They are a powerful tool to make an investment now, and pay for it later. It’s a fundamental aspect of our economy.
I get very irritated when a non-technical person tells me to take shortcuts to meet a deadline. Or – even worse – when a developer-turned-project-manager does so. Technical debt is often what made the project slow in the first place. And as a consultant being more and more specialized in “problem projects”, I’ve seen a lot of crappy code that grinds projects to a halt.
And yet, I myself tell teams to take shortcuts all the time. But there’s a difference. I know the codebase intimately. I know where it’s problematic, and where it’s under control. I know what is covered with tests, which parts are hurting us, and which parts are simply not elegant. And most importantly: when I introduce technical debt, I know how to get rid of it, and I refactor as soon as I feel it’s needed. I add comments in the code suggesting how to change it, and often I hang a sticky note in the backlog. Whenever new code is affected by earlier debt, I bump the priority of the backlog item.
When opinions are at odds, like in the quotes above, there’s often a problem in the language. There’s one term, and two concepts. In the interest of making the implicit explicit, I’d like to propose that we make a clear distinction between Managed Technical Debt, and Unmanaged Technical Debt. The former is defined as technical debt where most of the following conditions are present:
For Unmanaged Technical Debt on the other hand, most of the opposite conditions are present:
(Update September 12, 2013)
The photo above shows a project’s story map, and the bottom part is the map of technical debt, in columns per categories (blue stickies). The green stickies are prioritized, and the priorities regularly change: whenever we find that something makes us slower, the stickies move up. Sooner or later they move to the kanban board to be addressed in the sprint. We informally use the “three strikes and you refactor” rule of thumb, but mostly it’s gut feeling, experience, and discussion that help us decide whether something needs fixing – for example when we believe that future stories will be affected.
Visualizing the story map and the technical debt, is incidentally a great way to relieve stress: sure, there’s a lot of work ahead, but it never feels unmanageable.
(Update July 22, 2014)
Some people have started using the technique after seeing my lightning talk about it. Some early pictures:
Be sure to let me know your experience with if you’ve tried it as well!