Windows Confidential : Bring on the Lab Rats
Manipulating software developers can be a helpful strategy when fixing bugs during software development projects.
Raymond Chen
A major part of any software project is fixing bugs. Actually, fixing bugs is the largest part of most software projects. Managing bugs and the process for dealing with them is therefore an important part of the overall software development process.
In the early stages of a project, you may be rather lenient with bugs. You may be more inclined to accept anything, no matter how insignificant. At some point, though, you’ll realize you have a large bug backlog to handle. You’ll need to get more serious about your bug count. This cycle may repeat itself several times throughout the lifetime of a project. There may be a binge/purge cycle for each milestone.
One consistent source of bug backlogs is a disorder that a previous colleague of mine dubbed “bug-hugging.” Developers find bugs they feel they should fix, but simply haven’t gotten around to working on yet. As time passes, these bugs get older and dustier. The developers resist attempts to have the bugs declared not worth fixing or postponed to the next release, because they still feel those bugs really ought to be fixed.
It’s the software development version of hoarding. Developers become emotionally attached to the bugs, despite the lack of any rational basis for keeping them around. These bugs tend to be relatively minor. They’re often actually feature requests disguised as bugs—something like, “When I do X, it would be nice if there was an option to do Y.”
Call the Exterminator
On many projects, the effort to drive down the number of bugs is marked by a period (typically a week) where developers are challenged to fix as many bugs as they can. Normal rules for the order in which bugs should be fixed are suspended. Developers can fix any bug they like, regardless of priority.
For this week only, the focus is on quantity of bugs fixed, not severity or priority. There may be prizes awarded to developers who fix the most bugs, fix the oldest bugs, finish the week with the fewest bugs or get their bug count below a target level. Sometimes, managers bring in treats to keep the developers motivated.
The name for this week of focused bug-fixing varies from team to team. Some teams call it a Bug Bash, but that’s sometimes confused with another use of the term describing a focused effort to find new bugs rather than fix existing ones. Some teams prefer to call their bug-fixing week a Bug Smash. One team used the acronym MOABB (Mother of All Bug Bashes) to describe the week of focused bug-fixing.
Whatever you call it, the goals are the same. The immediate goal is to clear out as many bugs as possible, either by fixing them or by deciding not to fix them. The ultimate goal is to wrap up the week with a clear sense of the state of the project.
Bug-huggers are often targeted during these bug-fixing weeks. They face a decision point. It’s their last chance to fix the bugs they’ve always meant to fix “someday.” If they don’t fix them, the bugs are going to be taken away. At week’s end, the bugs will no longer be active, one way or another.
Hide the Cheese
During this week, management gets to treat software developers like laboratory mice. Software developers can be simple creatures. We think we’re an advanced form of human intelligence, but in fact, we’re as easily manipulated as hand puppets. Savvy managers can manipulate bug-huggers into choosing between fixing their cherished bugs or letting them go.
Management also realizes developers enjoy the thrill of breaking the rules. They’ll often employ a little reverse psychology by massaging the bug list so it only looks like a bug is unimportant. For example, they may reclassify all bugs they truly don’t care about as specification issues so that they no longer count as bugs. They may also take important bugs and give them a false low priority to make them look more attractive.
In the past, when some developers learned a bug-fixing contest was coming soon, they prepared bug fixes but didn’t commit the fixes to the project right away. Instead, they waited to unleash them during contest week. It didn’t take management long to discover this little trick. Now management includes bugs fixed in the week leading up to the official contest week in the statistics, thereby neutralizing the effect (and implicitly discouraging non-productive behavior).
This cat-and-mouse game between management and software developers is all just a distraction from the main purpose of the week: to fix bugs and improve the final product. And, despite their intelligence, developers don’t usually realize that they’re the mice.
.jpg "Lafe Low")
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. This article was written on equipment that has been in contact with tree nuts.