The development of Chef has been pretty interesting thus far. I had almost forgotten how much work is involved in getting an application shippable like this. My previous experience was with the release WakeUp! Alarm Clock, but that was as off-the-cuff as you can get: simple version control (umm, none at first then graduated to CVS); no bug tracking; no build process – builds were simply done on my development box; no unit test for regression testing (unit tests, what are those?!); and really no plan whatsoever. But I was in college and had no real experience in software, it was my first.
In these regards, Chef is completely different. I mean completely. My development environment is quite extensive in comparison to the days of old: Perforce for source control; FogBugz for bug tracking, support, forums and a bunch of other things; an automated build system driven by CruiseControl that give me a build and install at the click of a button; full NUnit test cases for the entire Chef API; and multiple VMWare environments for testing. Future posts may include some information on some of these topics, but for now a little information about FogBugz.
Late last summer when I really started working on Chef, I decided to install Mantis and use it for my bug tracking needs. It was free and tracked bugs and issues – a perfect fit. Then I began using it. The interface was pretty clunky, with options often placed in very unintuitive places. This was countered with the ability to create custom fields – perfect! Plus, did I mention it was free? I was ready to forgo some usability niceties for functionality.
But then I came to a point where I needed to organize issues by what release I had them planned for. I searched high and low, and the only way to even sort on a custom column was to drop down into code and add it myself. Not cool. I’ve got no doubt it was possible, but the sheer thought that I would have to modify the application to do something this basic was very off-putting. Two things hit me that evening: What happens when I have hundreds of issues and I do nothing but fight the software to get information out? and Why the hell do I want to spend time coding on my bug tracking solution when I have real issues in my app that need my time? It took about 5 minutes to figure those out and ditch Mantis.
So my search began. I had used BugZilla in the past and it did little more than frustrate the heck out of me. I looked at a few other open source solutions, but none of them were really all that impressive so I that’s when I turned to the commercial world. Everything I read pointed to FogBugz and it came highly recommended by a coworker. After an internal debate over wanting to shell out money, I signed up for a trial account and started using it. 45 days later it was clearly the tool I needed – bug tracking, release management, support email tracking, forums, etc. And best of all, it just works and gets out of the way.
FogBugz has a lot of nice capabilities, which I’m slowly learning about as I need them. For instance, it’s tied into my Perforce installation so when I check-in files they get associated with a FogBugz item and the modified files are displayed with that item. It isn’t a whole lot of help right now, but once real bugfixes are being rolled out, I can see this as being indispensable. Another of these features is the Release Notes. I’ve always hated trying to answer the question What’s New? Now I don’t really have to do much.
Since I specifically mentioned sorting and viewing data as being a pain point in Mantis, I’ve got to mention that FogBugz is extremely easy to extract information from. I can sort, group by, and filter by any of the fields available as well as the great fulltext searching capabilities. These are definitely a big plus.
If you’re looking for good tracking software that doesn’t waste your time then give it a shot.
The Johnson Blog 