OSCON 2007: Managing Technical Debt
Andy Lester is with the Perl Foundation, and maintains a blog at petdance.com.
Andy’s talk gave practical advice for catching up on all the tasks you put off until some later date (that inevitably never comes) — stuff like postponed docs, fixing broken tests (or just writing tests at all), backup regimes, TODOs in your code, etc.
He had a very simple and straightforward formula:
- Identify your debts
- Determine the costs
- Pay the most profitable
- Stop incurring new debt
- Repeat as necessary
The most important takeaway for me was the idea that you don’t try to fix all your problems at once. You figure out what fix will give you the most bang for your buck — not the easiest thing to fix, not the biggest problem. You fix whatever it’s the most profitable to fix.
There was also a lot of good discussion during this talk on how to convince a manager to allow you to begin reducing technical debt with things like refactoring, increasing test coverage, adding documentation, or actually testing your disaster-recovery plan. The best advice was the idea of putting it in terms that the manager can understand (often with a manager either in money or time).
For example, if managers know that investing two days testing disaster recovery would save weeks of rebuilding critical infrastructure, or that spending a week refactoring crufty old code would make it 20% faster to implement new features, it’s easier for them to justify the cost.
Andy has his slides available online here.