I picked up a copy of Joel Spolsky's most recent book, Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - it's well worth the ~$17 and beats every other book when examining the cost per word in the title. I'll be posting a review of this book once I wrap up the last 100 pages or so, but for now I wanted to touch on one of the points that make up The Joel Test. The Joel Test contains a quick, 12-point checklist that one can use to evaluate their software team.
Checkpoint #4 is, Do you have a bug database? Regarding that checkpoint, here's what Joel has to say:
I don't care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.
I am a software team of one, but, sadly, I don't use a bug database. In my defense, I employ another one of Joel's suggestions which helps mitigate the shipping of poor quality code: I fix bugs before writing new code. Development typically goes like this:
-
Client says, “Here are a set of specs,“ and provides a due date.
-
I map out my plan of attack and start implementing the features in that order. After completing a page, I run a number of simple tests and if I find any bugs, I fix them before moving on to the next item in the spec.
-
After completing the specs, I return the work to the client. I receive the next batch of specs while the client does more thorough testing on the work submitted. If the more thorough testing reveals more bugs, the client returns a list of bugs and repro steps, and fixing those bugs preempts current work.
This approach works, but I do think there would be advantages to a more formal bug database (rather than just the Word document from the client with the list of bugs they found along with repro steps). Having a bug database would provide a more formal listing of bugs, repro steps, and so on, allowing me to look back at the history of the project's bugs in a much easier manner. A bug database would also afford me the luxury of finishing the new specs before returning back to the bugs in the previous steps, thereby saving a costly context switch between writing new code and fixing old code (although the longer I wait to tackle the bugs, the longer it will take to solve them).
I thought I'd turn to you, my blog readers, and ask for your advice on a bug database. What tools/software do you use? Any recommendations for bug tracking for a company of one? In the simplest form I could just use a simple spreadsheet. But are there advantages to using more targetted solutions, like BugZilla, even for a team of one?
What bug tracking tools do you use, and what has been your experience with them? Do you agree with Joel that it's imperative that bug databases be used by software teams of one?