Bugtracking Lore
James over at Code Lore has a post up with some good tips on using bug trackers. This is great news because I have been planning to write a very similar post but have not gotten around to it. Prior to my departure from my previous employer, James was the Program Manager for the product I was working on. There were a few things we were doing that were kinda cool (or at least new to me) and worth blogging about.
First off, I don’t like calling them “bug trackers”. I prefer “issue tracker”. Everything should go in the issue tracker. This is how our team worked at Sensory and I thought it was great. New features, bugs, and any other tasks that have to be done- including things that will not result in code modifications- are all added to the issue tracker.
Having everything recorded in one place is vastly preferable to other methods that I’ve used- say where bugs are in the bug tracker but new features are “tracked” in a Word document lying around on a shared drive in a folder that’s rarely touched except by the guy who updates the document on the odd occasion when he’s had enough coding for the day. Such techniques are variously referred to as “lightweight” and “totally lame”.
And some random comments on what James wrote:
Logging - i.e., using the “comment” feature of the bug tracker to keep track of progress (or lack thereof). Yes. Yes. Yes.
Bug Triage - I didn’t do any of this since I was a mere developer, but I was present when James was on some of his bug triage rampages. They were brutal.
Scheduling - that is, keeping track of the estimated and actual amount of time spent working on an issue. I was quite skeptical when we started doing this, as I thought is would be too much work and too inaccurate to be very worthwhile. Most developer’s days are filled with many different activities, some done concurrently, so it’s often difficult to know how to allocate time to different issues.
I eventually realized that these numbers do not need atomic clock precision to be very useful. I use and recommend Joel Spolsky’s method for working out what time went where:
You do not really have to watch your stopwatch while you code. Right before you go home, or go to sleep under the desk if you’re one of those geeks, pretend you’ve worked for 8 hours (ha!), figure out which tasks you’ve worked on, and sprinkle about 8 hours in the elapsed column accordingly.
Joel is talking about using Excel for scheduling, but the advice applies just as well when using an issue tracker.
James also discussed integrating an issue tracker with a version control system, and I’ve got another rant about that in the pipeline.
