I've just finished reading The Art of Project Management by Scott Berkun and came across an O'Reilly posting by him and thought it was worth mentioning. He spends a moment discussing the top 10 ways NOT to fix bugs and I thought I'd discuss them a bit here.
10. Fix only the bugs that annoy your CEO.
9. Fix every bug (never ship).
8. Don't fix any bugs (ship today!).
7. Fix only the bugs that annoy your CEO's spouse/daughter/pet hamster.
6. Require approval for every decision from the most annoying and least intelligent person in your organization (possibly redundant with No. 10).
5. Start on a bug at random, and when you're halfway finished, switch to another. Repeat.
4. Play bug hot potato. Don't fix bugs, just keep assigning yours to someone else.
3. Put bugs in alphabetical order and fix them from A to Z, skipping vowels. (Hint: if you relabel bugs appropriately, this is equivalent to No. 8.)
2. Create a complex parliamentary system of delegates elected by two-thirds majority to draft a charter of bylaws and rules of order for the formation of three bilateral subcommittees empowered to moderate future strategic defect management discourse.
1. Spend all available time debating whether your current process appears on this list.
Some of these are obviously meant tongue-in-cheek, but at first glance, it seemed like I've seen all of these before. Let me reiterate his advice in the article: Should your manager suggest any of these, please stand up, turn around quietly, and run as fast as you can. If that's not an option for you, read on to combat some of these and demonstrate why they don't work.
First of all, you can't fix every bug. No software is ever perfect, fits everyone's needs, or acts exactly as expected under every scenario. Get that out of your head right now and you'll feel much better. Some bugs MUST be fixed, some SHOULD be fixed, some CAN be fixed, and some are not bugs, they are disconnects between what the user was expecting and what actually happened. If you address bugs in that order, you might actually get somewhere.
Next, overhead is the last thing you need. If your bug list is significant, you are likely late into the project and must move quickly and definitively. Unless you are changing architecture, interface, data structures, etc, you have to make things happen. Of course, a second mind in the game never hurts.
Finally, know who your customer is. If your customer is the CEO, then #10 and/or #7 might actually apply. If you are in this scenario, I pity you. Most CEO's want the most information available at any level of detail, with the slightest bit of effort, and with the flexibility and customization available with Excel. Good luck. If your customer is NOT the CEO but the he/she is still telling you about bug fixes, the sitatuation is almost as bad, but not quite. While this may be painful, it may come to a time when you have to say: “Yes Sir/Ma'am, I can work on that bug, but since we still have to ship on Friday, which other bug should I take off this list?”
There was a time when I had six bosses – ala Office Space – each prioritizing bugs/new code in different ways. If you're in this scenario, you have two options. You can start developing the attention span of a ferret and simply enjoy it OR you can direct them to each other and let them fight it out. Either way, at this point, you've lost the ability to direct your actions towards the best resolution of the project… therefore, these decisions have to made at a level where there may be some accountability.