Sunday, July 24, 2005

How Honest Can a Zero Bug Bounce Be?

I have mentioned before how much I like reading Adam Barr's blog. This time a read a post about a few bugs in Monad and a few peculiarities of communication inside the Monad team. What got my attention is these two paragraphs:


...

Anyway Lee filed this bug and I resolved it back to him as "By Design", but then a few days later he opened it back up saying "We really should fix this." So I chonked it right back to him. We are nearing a milestone and need to get our bug counts down; this means that using the bug database as a form of communication works pretty well because people check their bugs often, but I also don't want bugs lurking around on my plate.

...

I could blog about it, but not much point in displaying code that I know doesn't work (I have posted some code that could be improved, like the -contains to -eq change, but at the time I posted it I thought it was right). I could file a bug, but at this stage every bug filed raises the stress level. I could email him, but it might be hard to explain. I could go talk to him, but then I wouldn't have the script on my machine to show him. Hmf. And to think that our group, for whatever reason, doesn't use Instant Messenger, or that could be another choice.

...


Now, I am currently diving in the Rational Unified Process and I have studied the Microsoft Solution's Framework in the past, but I would say I am a newbie when it comes to formal software engineering processes.

However, I am convinced a bug tracking system is a critical tool. Also, I always thought that bug convergence and the zero bug bounce were concepts intended to help you identify the right time for a project to ship a release candidate and jump to the next phase.

Maybe Adam is talking with a bit of irony, but I think when you begin tampering with your bug count just because you have a deadline approaching, I see no way you can avoid your product's quality from suffering. I would say it is preferable to cut features than to cut quality.

Anyway, I know us developers are human, and we don't set deadlines. So let's stretch things a little bit and suppose it is ok to stop registering new bugs because your boss wants the bug count to reach zero by yesterday, or because the staff is stressed. Then, what are you going to do with the bugs you didn't register?

Dishonest accountants solved this centuries ago by keeping a second set of books in the shadows. They did it because keeping accurate information of what was really happening was more important to them than evading taxes.

2 comments:

Adam Barr said...

I totally agree that ZBB is really important and you should definitely not fiddle with your bug classification just to hit it. In this particular case it wasn't a "bug" in the usual sense of a failure/error. Lee was really asking for a new feature in the language (or at least a change in how the language works) and it's important not to randomize the project at that late stage (just before ZBB) with requests like this. That's why I resolved it back as "By Design". And in fact the MSH language solves this problem fine with the @() syntax.

- adam

Diego said...

Adam, Thanks for your comment. Now I understand better, but maybe I have few things more to say… In an upcoming post, ok?

Moving to MSDN

I haven't decided yet, but it is very likely that I will stop blogging here for some time. For some background, I have moved to the sate...