oreilly.comSafari Books Online.Conferences.


How to Decide What Bugs to Fix When, Part 1

by Scott Berkun, author of The Art of Project Management
Help Me Help You

Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right? Wrong. I'd bet that more than half of the buggy and unreliable software you've ever used was that way not because the developers didn't have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.

There are two challenges to making smart bug decisions: first, understanding how to make good bug-fix decisions; and second, creating and following a process that makes it easy to stick to those decisions when the pressure is high.

Wise leaders and smart teams know that toward the end of a project, milestone, or iteration, they'll be tired. They may be sleeping less, working more, and consuming frightening amounts of caffeinated substances. Thinking ahead, clever leaders put simple rules and survival kits in place early. Then, when times get tough, the resources for fast and easy bug fix decisions are already there.

This two-part essay is a primer on those rules and survival kits, giving you basics to follow. But more importantly, I'll provide the core ideas needed to make your own rules. The advice is organized into four levels, from scrappy first aid (level 1) to higher-caliber planning (level 4). But first, an entirely unnecessary but entertaining summary of approaches to avoid.

The Top 10 worst ways to decide:

  1. Fix only the bugs that annoy your CEO.
  1. Fix every bug (never ship).
  1. Don't fix any bugs (ship today!).
  1. Fix only the bugs that annoy your CEO's spouse/daughter/pet hamster.
  1. Require approval for every decision from the most annoying and least intelligent person in your organization (possibly redundant with No. 10).
  1. Start on a bug at random, and when you're halfway finished, switch to another. Repeat.
  1. Play bug hot potato. Don't fix bugs, just keep assigning yours to someone else.
  1. 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.)
  1. 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.

Hopefully, you've never seen any of these in action; and now that you've been warned, you can avoid them in the future. Should your manager suggest any of these, please stand up, turn around quietly, and run as fast as you can.

Level 1: First Aid

In the best web and software development shops, the management of bug fixing is like medical triage. Someone takes the lead role of going through incoming bugs and putting them into three or four basic piles. (This is called triage, bug wrangling, or defect management.) Like any large number of things you might have--CDs, books, debts, girlfriends--the only way to get a handle on bugs is to organize them into higher-level groups. That makes it easier to understand what you have, discuss it with others, and find an appropriately qualified therapist. As a universal rule, it's always easier to work with three or four piles of things than with hundreds or thousands of individual things.

So the best first aid when overwhelmed by bugs is to stop everything else for an afternoon and triage. (Test: if you can't remember the last time you did triage, you should stop reading and do it now.) You can't sprinkle magic dust on your bug database to put the bugs in order; someone courageous has to get in there, get their hands dirty, and sort things out. I promise you there is no way around this. If you're disciplined, you might be able to triage regularly, once a day throughout the entire project, never letting things get out of control. Or you might motivate every programmer to triage their own bugs frequently. That's great. But however you do it, it must be done.

Before you skip ahead, saying, "I know about triage, but I don't do it because of blah, blah, blah," know that triage is required for sanity in any first aid effort, whether medical or technical. There is no sense in putting a Band-Aid on a patient's scraped knee if there are a half dozen poisoned arrows in his back. Without triage, you have no way of knowing where the team's energy is best spent. And unlike the obvious seriousness of a patient frantically pointing over his shoulder to a quiver of uninvited arrows lodged in his person, your code base won't tell you where it hurts most. You have to figure it out yourself.

Triage forces other smart things to happen. By going through your bugs, the leader of the triage effort forces everyone to have a better view of the project. He'll find many bugs that are duplicates, already fixed, missing information (and in need of being sent back to the opener of the bug), ignorable, or simply ridiculous--for example, a complaint that the web site doesn't predict winning lottery numbers. It's common to see bug count numbers drop by 30 percent after the first triage, making it a surefire morale boost. But you can't get that easy win without doing the work.

Ultrasimple Triage

In terms of specific piles for sorting, there are an infinite number of ways to organize bugs, and every veteran has his or her own opinions on the best way. As usual, there's no single right answer. Use something simple, and plan to improve it next time based on what you learn and how things change for the next project.

The simplest scheme has three piles: Must Fix; Might Fix; Won't Fix. As you triage each bug, put it into one of these three piles. The more bugs that make it into Might Fix and Won't Fix, the more effective your triage is, as those piles represent clear decisions.

What you don't want is for 99 percent of your bugs to go into Must Fix; this is called "coward's triage." If everything is a Must Fix, you're saying that everything is equally important, which is meaningless. You've chickened out. Remember the golden rule: put bugs in the order most likely to lead to success. If all bugs are equal, there is no order, and success is improbable.

If you are doing bug first aid, aim for 50 percent Must Fix, and the rest Might Fix or Won't Fix. Put a stake in the ground and get serious about your bugs. Apply your judgment about remaining resources (time and people) and what you believe is most important to the project (customers and business). Late in a project, no leadership action is greater than the strong, proactive management of bugs and open issues. Aim for 50 percent Must Fix and push until it hurts; it's only when there's pain that you know you're doing real triage. ER doctors don't wave the white flag or call a time-out every time they're forced to prioritize one patient over another. If they can do it for people's lives, you can do it for bugs. So don't hide behind the ignorance of a coward's triage: get serious, get tough, and lead your team.

How to Keep Your Boss from Sinking Your Project

Essential Reading

How to Keep Your Boss from Sinking Your Project
By Andrew Stellman, Jennifer Greene

Like it or not, your project needs management. Yet few good software projects can survive bad management. If you're a programmer on a high-visibility project, this PDF offers five principle guidelines for managing upward that will help you help your boss make the right decisions about setting project expectations, working with users and stakeholders, putting the project on the right track and keeping it there. The PDF also covers what problems cause projects to fail and how to fix them, and what you can do to keep your software project from running into trouble.

Read Online--Safari
Search this book on Safari:

Code Fragments only

Pages: 1, 2

Next Pagearrow

Sponsored by: