Using the "Five Why" method to get traction on your defects and technical debt.
When you ship software, you really ship at least these things.
- Features
- Bugs
- Defects/Technical Debt
Features are what we mean to ship. Bugs are what customers see and don't like. Defects require a bit of explanation. Defects are all the problems we know exist in the system that aren't visible on the surface. Lack of unit tests, difficult install procedures, poor design patterns and outright hacks to fix last minute bugs all fall in this bucket. You can ship lots of features and zero bugs, and still be in trouble. That's sort of a scary thought. Your product is now a ticking time bomb. The next release cycle is already doomed and we haven't even locked down the feature list.
I have seen projects go here many times, but I never had a good plan for how to tackle the problem before. Ground up re-writes are expensive and I don't believe in them anyway. Spending and entire release cycle working on automation and refactoring doesn't sound like fun and by the time you are done your product may no longer be viable in the market without new features. What we need is a way to incrementally invest in improvements that pack a lot of punch.
Enter Eric Ries's blog "Lessons Learned". Here he dissects Toyota's method of defect prevention and applies it to software. The crux of technique is to ask recursive "why" questions for every bug, track the defects you discover then fix the ones the come up a lot and/or cause the most pain. I'm dying to try it out and see how it works.