Way back in the dinosaur days, I used to work for IBM trying to make DB2 a more usable product (which is a little bit like saying that I was on the tiny little team responsible for making sure that the faucets on the sinks in the bathrooms in a Boeing 747 had good hand feel). Despite our valiant efforts, almost every user of DB2 completely ignored the beautiful Graphical User Interface that we painstakingly built and relied instead on the super-fast and highly efficient Command Line User Interface, into which they typed gobbledy-gook like:

quiesce tablespaces for table dogfood

and magic ensued. We were never entirely sure how to convince them to abandon their command lines and flock to our world, and so I spent a lot of time scratching my head and drawing things on white boards and buying users dinner in an attempt to find the secret sauce. I left IBM well before the mystery was cracked (if it ever was), but the wisdom of the many moons which have passed has granted me some insight I wish I'd had back then. After today's talk by Joel Spolsky, I can safely say that it's insight Joel shares.

They key is that you have to eat your own dog food. We talked the talk a lot but we weren't really Database Administrators (DBAs) so much as we were a bunch of Human Factors Specialii trying to penetrate the remarkably High Priest like mentality of the people who manage the incomprehensibly large databases that run our lives. When I needed to try something in DB2, I started it up on my laptop and did something in the GUI and then puzzled about why our users wouldn't just do the same, but I also didn't do that task a hundred times a day every day or else I would have written a handy CLUI macro I could invoke in two keystrokes. Joel and the good folks at Fog Creek Software get that, which is why FogBUGZ is such a fantastic piece of software. Those of you who read Joel on Software regularly will know that Joel has some pretty sharply defined viewpoints on how to manage teams of developers and keep software projects on track, gained largely through his many years of experience in the industry on big and small teams. His insights and opinions are baked right into the product, which means using it is like having Joel perched on your shoulder, guiding you and your team at every turn. I paid close attention during his demo, looking for all of the places where I could see his advice manifested in FogBUGZ, including:

• Building software is a three phase process (the Art of design, the Engineering of the actual product, and the Science of debugging — see Seattle). This manifests in the way FogBUGZ breaks down into separate components (Wiki for specs and other documents created during the design, Project Management and Evidence-Based Scheduling (EBS) for managing the development, and bug tracking and email/discussions for handling the debugging).
• Joel has spoken at length about how to pick a release date for your project which is reasonable and which you stand a good chance of hitting (see Picking a Ship Date and Painless Software Schedules among many others).  This used to seem a bit like black magic, particularly if you were trying to pick a date that you had some faith in rather than just, say, throwing darts at a board. The new Evidence-Based Scheduling features in FogBUGZ 6.0 are pretty remarkable in that they provide a very realistic view of your probability of meeting your ship date as your project progresses, based on the ability of your team members to accurately estimate the time required to complete their tasks. Joel explained how the calculations work (Monte Carlo Simulations!) and it's all quite clever, but the important thing is that it lets you look at a graph that says our probability of shipping on January 3rd is 8% while our probability of shipping on April 20th is 98%.
• He told a story about how they've been using FogBUGZ internally for many years, but even up to v5 he noticed that he would come in every morning and open a little Notepad window to track the two or three things he needed to do rather than actually open cases. So they ate their dog food for v6 and created a method to open new cases which is as easy as typing lines into Notepad, and now he stores everything in FogBUGZ properly.
• FogBUGZ doesn't support the idea of pooling people into a single resource for handling a task, largely because they feel that you should have a single person responsible for every task. Likewise, you can link cases together but there isn't a concept of dependencies like there is in Microsoft Project, because they believe that they don't actually occur that often in software (which led to a funny story about how the Project team at Microsoft doesn't use Project to manage building Project because when they tried, it produced a Gantt chart 9,000 pages wide).

We've been using a combination of Project, Mantis, and an internal time tracking application to manage our process, so we were very interested in whether FogBUGZ could replace our current mishmash of apps with a single tool. We'd need seven seats now so would likely go with a ten pack ($999 until November 1st), plus a service agreement for the same ($182.50 per year), so it's a non-trivial decision to make the switch. It looked like it was frustratingly close to what we need but missing the ability to analyze estimates and probabilities across projects (i.e.: the EBS features are based on a single project rather than looking at tasks assigned to each employee in every project). You do have the ability to define what percentage of time each team member spends on FogBUGZ tasks but it's for all projects, rather than being able to define a percentage of time spent on each project. All the same, I think we might give the 45 day free trial of FogBUGZ On Demand a try. I'll report back on what we love or hate and whether we make the decision to switch. Stay tuned!