I recently published an article “Technical Debt a Perspective for Managers”. On another forum I got the suggestion that the team should take a break every couple of months and spend a week paying down their technical debt. From personal experience this sounds a like a great idea but it ends poorly. Here’s what I see happen in this case:
- Management (and others) expect miracles to be performed every time you have a technical debt week. They expect the team to make the code perfect. Of course we never get done quite as much as we hoped.
- Developers delay making the smallest changes and improvements saying we have to put it off to technical debt week. The net result you have way more stuff to fix than you have capacity during debt week.
Like a mortgage (or credit card debt), you’re best off paying it down on continual basis. I encourage teams I coach to acknowledge that 10-15% of their time will be spent on an ongoing basis paying down their debt. That’s for greenfield apps, older apps will have to spend more. When you pay off your home mortgage you make payments as soon as you have the money from your paycheque. Delays just add interest charges, lump sum payments are a nice addition to regular paydown but not a replacement. Technical debt is the same way.
Mark, in essence we agree entirely on the approach. I thought I’d share a slight twist on the metaphor that I find useful. Here’s my thinking…
Why does technical debt hurt the business? Because it slows down the ability make changes in the future, realized as higher maintenance costs and increased cost for future development. That doesn’t sound like debt to me, because debt gets worse even (especially!) if you don’t do anything. The quality issues we’re talking about only get worse if you continue to change the same area without cleaning it up.
Because of this, I’ve started talking about it as a tax on future development. Luckily, it’s a tax you can reduce if you clean things up (kind of like carbon offsets or pollution taxes, maybe?). Like most taxes, it has different rates for different things. In the development world, this tax manifests as a higher cycle time on the items affected. If you continually are working in the same area, you should invest to reduce the tax for that area. If you rarely (if ever) make changes to an area, you shouldn’t go out of your way to reduce the tax, because it’s not really hurting you. (e.g. How often do you rewrite reasonably solid 3rd party control packages? How often do you rewrite an open source library because you don’t like some details of the design or their coding style?)
Even more importantly, to me, the tax metaphor is one that my stakeholders can understand quite easily, and it helps them understand why some areas of the system are really hard to change and others are quite trivial.
Thoughts?
Eric – I like the metaphor. The small problem I see with it is we don’t always know where these mistakes will affect us. We think just because they’re only in part of the code that is the only place they can be an issue. But sometimes they change the shape (i.e. interfaces) and so have a much larger affect than we expect.
Cheers
Mark