FogBUGZ 3.0 is now shipping! This is a really huge upgrade; FogBUGZ moves up from being a simple bug tracking package to a rather robust management system that handles the entire development process.

One big theme of FogBUGZ 3.0 was “listen to your customers.” If you use FogBUGZ you can get feedback from your customers via email or the web. You can even add a menu item to send feedback in your application, or catch crashes from the field and submit them directly into FogBUGZ like we do with CityDesk. Customer suggestions can become feature items, prioritized and tracked alongside other development tasks.

Here at Fog Creek we started using the email integration component to handle all customer service email that comes into the company. Instead of using a lame single-user email client like Outlook, we now have a web interface that shows everybody messages as they come in, which anyone can assign, track, and prioritize just like bugs. And a complete record of every customer email interaction is kept in FogBUGZ for all to see, so anybody in the company can pick up the thread of a conversation with a customer. If your company-wide email aliases (“info@little-hope-inn.com”)  are causing problems, you should look at FogBUGZ, even if you don’t use it for bug tracking at all.

Inspired by the Extreme Programming idea of prioritized user stories, FogBUGZ lets you maintain lists of features, ideas, bugs, keep them prioritized at all times, and always work off the top of your list. If 3×5 cards or big whiteboards don’t cut it for you, FogBUGZ is a great way to do Extreme Programming. (Read about how the Six Degrees team did it.)

I’m also happy to say that FogBUGZ does not have certain features that seem sensible but which experience shows reduce the overall effectiveness of the product. I’ve already talked about custom fields, which are dangerous if used inappropriately, but there are some other things that FogBUGZ intentionally does not do.

For example, inspired by software testing guru Cem Kaner and of course Dr. Deming, FogBUGZ does not provide individual performance metrics for people. If you want a report for which programmer makes the most bugs, or the infamous “which programmer has the most bugs that they allegedly ‘fixed’ reopened by testing because they were not really fixed,” FogBUGZ won’t give it to you. Why? Because as soon as you start measuring people and compensating people based on things like this, they are going to start optimizing their behavior to optimize these numbers, and not in the way you intended. Every bug report becomes an argument. Programmers insist on recategorizing bugs as “features.” Or they refuse to check in code until the performance review period is over. Testers are afraid to enter bugs — why antagonize programmers? And pretty soon, the measurements give you what you “wanted”: the number of bugs in the bug tracking system goes down to zero. Of course, there are just as many bugs in the code, those are an inevitable part of writing software, they’re just not being tracked. And the bug tracking software, hijacked as an HR crutch, becomes worthless for what it was intended for.

We long ago decided that to make FogBUGZ successful, it needs to reflect and enforce as much as we know about good software development practices. That’s why I’m very proud of the product we released today. Check it out, there’s a free online demo. If you buy the software this month we’re giving out free copies of Mary Romero Sweeney’s great book. And if you’re using any other bug tracking method — commercial, open source, or Excel files on a server — we’ll let you take 30% off as a competitive upgrade.