If you’re a software nerd, chances are you’ve heard of FogBugz and probably read the Joel on Software blog. I’ve never used FogBugz, but I’ve used a number of bug tracking systems and have learned a lot of lessons about how bug tracking “should” work in a large organization. I walked through the FogBugz tutorial, assuming I’d see some of my common troubles solved. Since Joel is an outspoken expert in the software community, I presumed that the bug tracking software would be very well thought out. It certainly was appealing to look at.
But, one of the first questions I had, and couldn’t figure out from the documentation and tutorial is – how do you handle a bug that spans multiple releases? It’s a pretty simple question. If you have a bug, and it exists in release 3.0 of your product and onward, how do you mark it? Let’s say you decide to fix it in release 4.2 and 5.0 of your product, but you’re not going to fix it in 3.x or 4.0. How do you indicate that?
This isn’t an uncommon problem or question. If you’re working on a product with multiple releases, it’s pretty basic. So, being unable to tell from the screenshots, I e-mailed Fog Creek Software. Short answer is – a bug can’t span releases. If you want to indicate that a bug exists in 3 releases, you copy the bug 3 times. I was, at least a little, surprised.
If you take my example, that would mean that you have to create the bug and put it in version 3.x. Then copy that bug for 4.x and 5.x. You then close the 3.x version, since you’re not going to fix it there. You’re left with 2 open bugs. Let’s say the engineer (and this is not unusual) goes to fix the bug and finds out “hey, these aren’t really the circumstances under which you’ll see this bug” and the engineer, being a diligent worker, goes back and updates the bug description/title to be more accurate. You want to keep bugs as accurate as possible, especially if you’re in an environment where your bugs are user-searchable, or partner-searchable. Maybe the conditions that the engineer found the bug occurs under are actually pretty rare, which would likely mean decreasing the severity/priority of the bug because most people won’t see it.
Well, now the engineer has to do all of that in 3 places. You can’t just ignore the 3.x copy of the bug, because you don’t want a customer running 3.x to think that they might encounter that bug without letting them know about the conditions. So, the good engineer updates all 3 bugs.
This is just the beginning of the problems you have when you don’t provide a consistent view of a single “bug.” Let’s say the engineer fixed the bug in 4.2, but forgot to fix it in 5.0. Because the 5.0 bug is a seperate entity, it isn’t easy to tell at a glance that a regression is about to be introduced. If 5.0 goes out the door without that bugfix, and 4.2 had it, that means 4.2 had something that 5.0 didn’t… and that’s a regression. Customers hate regressions more than anything. Some customer is going to move from 4.2, where everything worked great, to 5.0 and find stuff broken, and be pissed.
That’s why, to me, having a single coherent view of a bug is essential to any medium-to-large scale software project. Creating extra documentation for engineers to write, and others to read and manage, is anything but simple or elegant. For one of the industry’s biggest pundits to ignore this in his own bug tracking system seems quite a shame.
UPDATE: FogCreek got back to me and did indicate that you could use a custom field to handle this scenario. I’m still surprised that this is uncommon enough that it’s not available out of the box.