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.
Learn about this Book
FREE Sample
August 6th, 2007 at 9:29 am
I’m assuming based on your example that “profit” isn’t just talking about a monetary measurement.
August 7th, 2007 at 1:36 pm
Exactly — in this case ‘profitable’ is whatever is the most useful to you per amount of time and effort spent. So, basically, concentrate on whatever fixes will give you the most “bang for your buck.”
August 8th, 2007 at 3:15 am
Another point Andy made about selling your manager on changes is that it can be helpful to tell *stories*, either cautionary or exemplary, about similar events and changes that the company has been through — stories that support the idea of doing the project you want to do.
August 14th, 2007 at 12:26 am
The key to stories is that it puts your concerns in terms that management can understand. Management understands dollars and days, so your stories should tell that. Don’t say that “we have to have referential integrity in the database!” We geeks too often feel that other people should just understand what we’re saying.
Instead, say that “If we take a week to add referential integrity and foreign keys to the database, we’ll make coding safer, and will probably cut down on errors. Remember that Foo project and we blew the deadline by two weeks because we had an extra three weeks of bugs that we had to close? Most of that was caused by bugs that would have been caught if we’d had foreign key constraints in place. We want to prevent future screwups like that.” That’s a story that your boss can get behind, and one that he can explain to his boss, too.
August 14th, 2007 at 8:27 am
Thanks again for the talk, Andy. A lot of excellent ideas in there.