- First of all, bugs vary greatly in size and scope. Something like "there's a typo in this dialog" is a bug. Something like "I think that we should swap the positions of these two buttons" is a bug. Something like "we should rearchitect our caching system to support this particular scenario" is a bug. That enough seems like a large enough problem to cause managers to avoid doing too much planning based on peoples' bug counts.
- Second of all, you only have so much control over your own bug count. Some bugs can't be fixed, some shouldn't be fixed (either they're too obscure to be worth the time, or perhaps the tester who filed them didn't realize the implications of their erroneous suggested "fix"), some were filed incorrectly (they forgot to do X first). But, worst of all, your bug count depends heavily on how eager the testers are at assigning you bugs. If you got ten bugs filed against you between 8:00 and 10:00 on Monday (this happened to my manager), suddenly you look like you did almost no work last week.
- Then, there's even potential for some strongly negative behavior when you focus too much on peoples' total number of bugs. The FrontPage bug counts are historically some of the lowest in Office, but recently, we haven't been as low as we used to be, partially due to some structural rewrites, and partially due to a big recent test sweep of things that don't normally get tested that much (extremely long translated strings in dialogs, 72-pt title bars, white-on-black color schemes, etc.). So, a the managers decided that we should all try to fix 2/3rds of our bugs over the next few weeks. This is stupid. It even encourages some bad behavior: people assigning their bugs to someone else on Fridays, saying, "hey, can you take a look at this?" just to get it off their counts, people marking bugs as "fixed" even when they're only "pretty sure" they have a solution, and people spending sixteen hours on the weekend trying to get their bug counts down to the point where they thought they'd be before their tester went overboard Friday afternoon. To be honest, these negative effects (except the weekend hours) have been few and far between in my observations, but I still think that it sets a negative trend, and shifts the focus away from understanding each developer's unique situation.
- Finally, there are essentially punishments for fixing too many or too few bugs. If you don't fix enough bugs, then you have to deal with telling your manager that you didn't get done what you thought you could get done. There's no penalty, but it's still something that everyone would like to avoid. If you put in a lot of extra hours and fix too many bugs, then suddenly your counts are low, so people feel the need to shift some of their bugs over to you. I just "won" FrontPage's image handling code because of my low bug count.
Unnecessary and unhealthy obsession over bug counts is my number-two grief about working at Microsoft. My number-one annoyance is that everyone on my team spends way too much time in the office. Nobody tells them to, they just do. For some, it's because they have nothing better to do. For others, it's because they feel pressured to keep up with the rest of the team. I don't spend that much more than 40 hours a week in the office, so I'm basically now a slacker compared to the rest of the team, which annoys me greatly. But, I guess I'd rather be a slacker and get paid the same amount as someone else on the team who doesn't have time to themselves because they're always working.