Republished from my old 4cups.rs blog post from September 15, 2012.
Two weeks ago, I got frustrated with the hundreds of bugs and feature requests in our database. So I deleted the whole thing. Then an odd thing happened: we started fixing bugs. We fixed almost 30 bugs last week, easily our best bug fix rate since I've been at GameChanger.
Joel Spolsky inspired me with his post on Software Inventory. I followed his advice almost to the letter:
At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.
- Suggestion: use a triage system to decide if a bug is even worth recording.
- Do not allow more than two weeks (in fix time) of bugs to get into the bug database. If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs.
- Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.
In our release cycle, two weeks is an eternity. So we don't wait for two weeks of bugs to pile up. We wait until our bug column in Trello is roughly a screen-and-a-half tall.
Then we fix bugs! Our new bug column is too small to ignore. Some of the bugs that popped up were old bugs that customers had complained about for months. They had nowhere to hide in our tiny Trello column. So we fixed them.
The normal Huge Bug Database works in the opposite way. It requires a triage system (meeting), which requires agreement on a system of priority and severity (something to argue about). Then there needs to be some sort of scheme (meeting) for scheduling bug fixes along with feature work. And someone's got to make sure (emails) that the small percentage of Chosen Bugs are actually fixed before release goes out. That's a ton of meetings, arguments, emails, and management for little benefit.
Instead of documenting, categorizing, and scheduling bugs, we're fixing them and going back to writing features. Yay!