How to Decide What Bugs to Fix When, Part 2
Pages: 1, 2
Exceptions and Notes
There are some special cases where you can skip the advice mentioned in this two-part essay. If you've been waiting to pounce on me for some horrific oversight, hopefully I've beaten you to it.
Low-hanging fruit: Sometimes a programmer can knock off low priority bugs while they're in the right part of the code for a high priority bug. In this situation it's okay to fix bugs out of priority order. Let them use their discretion. Opportunistic bug fixing just makes sense.
Morale: fixing hated or visible bugs, regardless of priority, can build pride and raise morale. It's okay to do this if you know that's why you're doing it. If you do this often, change your criteria for what priority 1, 2, and 3 mean to reflect visibility. If you keep bending a rule, change the rule.
On the clock / off the clock: Make sure programmers are clear on use of their own time vs. clocked time. It may be fine for them to fix low priority bugs or work that interests them if they're doing it off the clock. And make sure everyone is clear on whether or not this kind of work counts towards bonuses.
Bug fix quality: Bug fixing is like any other kind of work: the more time you spend on the work the higher the quality of the bug fix. As a rule of thumb the bug fix should match the quality of the work it's being checked into. You wouldn't put gold hinges on an plastic door unless you had a really good reason.
Frequently Asked Questions
Who should be involved in triage (Level 1)? Whoever yells loudest. Failing that, it's the programmer, tester, and project manager. If one person can lead triage and filter out duplicates or garbage bugs, that makes sense: don't waste three people's time doing what one person can do alone. If you have a representative from the customer on site, ask them to participate as well (but be willing to translate the bug into their terms). All specialists, documentation, usability, marketing, should be invited, but it's often the best use of everyone's time to just have them available by phone if their input is needed. Let them know which bugs are going to be covered so they can show up if they care about particular ones.
What if I can't get my boss to agree to setting exit criteria (Level 3)? Study hypnosis. Okay, do it for one part of the project as a pilot. Get the individuals who work on that area to work with you and contribute (or at least to understand what you're doing). Do it alone if you have to. Then when the project is over, review with the boss whether your use of exit criteria was helpful. If it was, he'll likely want to use it elsewhere. If it wasn't helpful, why would you expect him to agree? Repeat until you find something, exit criteria or not, that helps.
What is your worst experience with defect management? Well, there is the story of the QA manager who finished defining the exit criteria two days before we shipped. He seemed happy about his progress, but looking at what he wrote, I wasn't surprised to find that he'd documented the current build. You can guess what the quality of that release was like (it wasn't his fault: the VP pretended to delegate exit criteria, but really just kept it in his head).
Why isn't defect management taught as part of most computer science degree programs? Perhaps their curriculum planning is defective? To be fair, there's only so much time even in four years. I suspect that, from an academic perspective, defects and bug fixing are more about software production and the craft of programming than about understanding the core concepts of computer science. At a trade school, where the focus is heavily skewed towards employment, more coverage is given to production. And some four year schools do offer electives in quality assurance and debugging techniques.
Software testing: This is a big subject and I've given you a quick, dirty, and skewed introduction. Start here: http://en.wikipedia.org/wiki/Software_testing.
Painless bug tracking: An excellent essay from Joel on simple bug tracking.
Examples of bug triage/prioritization: Here's a sampling of how different organizations handle triage. Diversity in these links is intentional.
- Bugzilla: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
- OSAF: http://wiki.osafoundation.org/bin/view/Journal/KatieParlante20040726
- Gnome: http://developer.gnome.org/projects/bugsquad/triage/faq.html
- Microsoft video of a triage session: http://channel9.msdn.com/ShowPost.aspx?PostID=26948#26948
- An approach to tracking bugs (for ASP.net 2.0): http://weblogs.asp.net/scottgu/archive/2004/11/03/251930.aspx
Software quality assurance FAQ.
In April 2005, O'Reilly Media, Inc., released The Art of Project Management.
Chapter 3: How to figure out what to do (PDF) is available free online.
For more information, or to order the book, click here.
Scott Berkun is the best selling author of Confessions of a Public Speaker, The Myths of Innovation, and Making Things Happen. His work as a writer and public speaker have appeared in the The Washington Post, The New York Times, Wired Magazine, Fast Company, Forbes Magazine, and other media. His many popular essays and entertaining lectures can be found for free on his blog at Scott Berkun.
Return to ONLamp.com.