Bugs should not be logged?

Here’s a fun one. I came across an article explaining why bugs should not be tracked via a post on Joel on Software. As I read the article, I oscillated between outrage and amusement. Could this guy really be serious?

I considered the possibility that Mr. Thorup just wasn’t experienced in software development, and then I thought that perhaps he was being intentionally outlandish in order to make a point. I’m leaning toward the latter.

No matter. Let’s take his idea at face value and examine it.

To summarize the article, Lars suggests that the ability to log a bug breeds a casual attitude toward these bugs. Log it and forget it. Out of sight, out of mind. Better to deal with the little beastie right now, or if now isn’t doable, then at least keep the bug somewhere close-at-hand. A post-it on your monitor. A bug report in a database, says Lars, adds no value to your software. It’s unnecessary overhead, and it not only can be eliminated, it should be eliminated.

Fair enough, and all things considered, a pretty healthy attitude towards software development. After all, I’ve long been a proponent of using only as much process as is needed for the task at hand. So why am I not beaming with excitement at the prospect of ditching my bug database?

Simple. Two reasons: workflow and usability.

Workflow should be pretty easy to understand. It’s really difficult for one guy with a fist-full of post-it notes to scale a bug tracking process up to deal with more than a small workgroup. Throw in a remote tester / user / developer / manager, and you’re cooked. Simply put, the larger your project, the more people are going to be involved in the process. There are guaranteed to be cases where the person who’s reporting the bug isn’t the person who needs to fix it. In fact, the person who’s reporting the bug may not even know who’s supposed to fix it. This implies workflow, and that isn’t satisfied well with post-its.

Of course, the post-it that falls off the wall of shame and behind the desk will kill you, too.

But what does usability have to do with tracking bugs? Besides the really clever segue from my last post, the way you handle bug reports has a very real usability factor for your users and testers, and your developers, too. Again, for small shops and small projects, I can see the value of hollering, “got another one!”, and then slapping another yellow square on the wall.

Lars suggests that the optimum approach is to fix the bug as soon as it’s seen. Great — as long as the bug I see is my own, and and long as the fix can happen quickly without tearing me off of whatever I was working on when I found the bug. If I find a bug in an area of the code I’m not familiar with, or if the fix for the bug is going to turn into a non-trivial refactoring effort, I really have to question whether you want your developers dropping everything to play exterminator.

How about when users or testers find bugs? Every developer fights a constant battle to get “into the zone” — it takes time to get your head into a design or coding task, and interruptions cause a loss of productivity entirely out of proportion to the time apparently taken by the interruption. This is the premise behind point #8 in Joel Spolsky’s 12 Steps to Better Code — be sure that developers have quiet working conditions. If you have testers and users running up to developers every time they think they’ve found a bug, the developers quite literally won’t get anything done.

Say “yes” to frequent interaction, but say “no” to real-time interruptions.

This, by the way, is the same reason that computer architectures make use of asynchronous channels like message queues. It is far more scalable and efficient to let multiple subsystems operate with a little buffer between them, lest all of the component parts get hung up waiting on one another.

A bug database can also be more user-friendly to someone reporting a bug. Consider what would happen if you made every tester and user run a gauntlet before you accepted a bug report. Is this bug already logged? Is it reproducible? On our system, too? Is this bug *really* important enough to work right now? Don’t you think we should walk around to see the other stakeholders to see if they agree that we should make this change right now?

Never mind.

Your goal when tracking bugs is not to collect the smallest number of bugs. In fact, if your bug reporting mechanism is working well, you’ll probably get a ton of feature requests and product suggestions via bug reports. Don’t flog these users for improper use of the bug system. Thank them for their feedback. It’s far easier to categorize bug reports into feature requests than it is to guess what your users are thinking.

Make bug reporting as easy as possible for testers and users. The closer the testers are to your team, the more you want to work with them to educate them on what makes a good bug report, because that will save everyone a ton of time, but for the beta testers, non-technical testers, or users, just take whatever they’ll give you. The alternative, in many cases, is to just not learn about their experiences, and you can’t recover that lost data.

To log or not to log? No contest — you won’t catch me without a bug database any more than you’ll catch me without source code control. It’s just not going to happen.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>