In this post I compare BugTracker.NET to FogBugz.
(BugTracker.NET version 2.5.7, FogBugz version 6.0.29H)
FogBugz is the most important influence on BugTracker.NET's in both UI design and philosophy. Philosophy? FogBugz and its creator Joel Spolsky (his “Joel on Software” columns are among my favorite things to read on the web, pretty much up there with King Kaufman on Salon) do have a philosophy, as stated in the FogBugz help file:
"Avoid the temptation to add new fields to FogBugz. Every month or so, somebody will come up with a great idea for a new field, for example, keeping track of the file where the bug was found, or how often the bug is reproducible, or which exact versions of which DLLs were installed on the machine where the bug happened. Don't add fields. If you do, your new bug entry screen will end up with a thousand fields that you need to fill out. Suddenly, you have a high ceremony bug tracker that nobody wants to use because there are so many required fields. For FogBugz to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will start sending emails on the side, and issues will get lost."
I agree with the anthropological wisdom in that comment. Both FogBugz and BugTracker.NET allow you to create an issue by just entering a one line short description. You don't have to choose a project, version, category, severity, etc. You can add those later. The important thing is to capture something. At my real job, my job, we use MKS Integrity for both version control and bug tracking. The administrators have set it up so that there are a good dozen required fields one has to enter to report a bug. If you are quick - and if the MKS server isn't about to crash - you can enter that bug in about two minutes. I can testify that just that two-minute hurdle is enough to discourage people from interrupting what they are doing to enter a bug they may have noticed along the way.
A design goal of both FogBugz and BugTracker.NET is to keep the email conversation about an issue WITH the issue. Often the real story is in the email thread, not in the comments posted to the bug. Both FogBugz and BugTracker.NET accomplish this in the same way: You can send compose and send an email from within the system and you can have the system receive emails from a designated POP3 inbox and post them into the system. FogBugz was the example that I was copying when I created this feature in BugTracker.NET.
A picture is worth a thousand words
Another feature in BugTracker.NET that I copied from FogBugz was the ability to take a screenshot and post it to the tracker in a minimum number of clicks. Both FogBugz and BugTracker.NET come with dedicated utilities for capturing a screenshot, annotating it, a posting it to the system. In fact, it was seeing a description of the FogBugz utility that motivated me to write my own. Again, the easier you make it for people to post information to the tracker, the fewer issues will slip between the cracks.
Both systems can display screenshots inline, in the flow of the issue narrative, so that you don’t overlook them when you take a quick glance at the issue and so that you understand the images within the flow of the narrative.
Compare [Fogbugz screenshot] with [BugTracker.NET screenshot] which show how images and emails are displayed inline.
(By the way, in BugTracker.NET, you configure whether posts are displayed in ascending or descending chronological order)
FogBugz, the big picture
FogBugz costs about $200 per person, but right now on their website they are running a deal where you can get a 10 user license for about $100 per person.
The overall look, feel, and… intelligence…of FogBugz is dazzling. Extremely well crafted, deeply thought through. Even though it is a web app – and I was trying out a demo version hosted at FogBugz - it feels rich and zippy. It’s a terrific piece of Ajax Web 2.0 programming. It’s fun to play with it. Is that too geeky of me? To me as a developer and a, sort of, competitor, it’s inspirational.
FogBugz has some major, useful features integrated into it that have no counterpart at all in BugTracker.NET:
- Discussion forums
- Integration with Visual Studio
Time tracking and schedule estimation tools
So, what’s NOT to like in FogBugz?
As I said, FogBugz has a philosophy, and if you don’t agree with that philosophy, then FogBugz isn’t for you. More specifically, it comes with a built in issue workflow/lifecycle that you can’t change (as far as I know).
Here’s a simple way that some organization might want to use a tracker. Let’s say you have two groups, programmers and testers. On Monday, a programmer fixes a bug and checks it into the source code versioning system. He marks the bug as “Checked in”. Since he’s a programmer, he is not allowed to mark the bug as “Tested” – only a tester has the permission to do that. On Tuesday the development build manager creates a build so the bug is now in “Ready to be Tested” status and should show up in the testers’ work queue. On Wednesday, the tester tests it and can either mark the status as “Tested” or “Failed”. A tester can’t mark the bug as “Checked in”. Do you get the idea? There are roles, there are statuses, legal transitions from one status to another, and only people in the proper proper are permitted to change a particular status to some other particular status.
In BugTracker.NET, you can define your own statuses and you can define your own query filters to react to the statuses so as to, in effect, create a workflow. BugTracker.NET does not yet – and might never - have the concept of roles associated with statuses, so you can’t create restrictions that say only somebody in the role of “tester” can set a bug into “Tested” status.
In FogBugz, you can’t even create the statuses. You can assign the bug to somebody, and, I guess, by virtue of who you assigned it to, that’s the proxy for the status. If I missed something in FogBugz, or I’m misunderstanding something, please do let me know. I think maybe a team could contrive a way of using FogBugz to approximate a developer-to-tester work flow. But they would be swimming against the flow, doing something that FogBugz seems to deliberately discourage.
If the feature of enforceable workflow rules is a must for you, then neither FogBugz nor BugTracker.NET is a good fit. But, if you must have a workflow as I’ve described, even if it is not enforceable, then BugTracker.NET might be a better fit, because at least it lets you come up with your own statuses and because it lets you define any view you want.
I think any team looking for a bug tracker should try out FogBugz. It’s interesting and fun. But if you feel locked in by its restrictions, or if you LIKE FogBugz but want to try a free alternative, then try BugTracker.NET too.
BugTracker.NET was written to be very open and configurable. Things you can do easily in BugTracker.NET without changing code, that you can’t do (as far as I know) in FogBugz, include:
- Add your own custom fields, including making them required. Like Joel, I’m actually not very sympathetic to adding more fields. In fact, I make it easy to remove even the basic built in fields from the page (using css). But my users wanted to be able to add custom fields, so I accommodated them. I think the built-in fields that FogBugz has chosen are enough.
- Extend it by adding your own pages.
- Changing the “branding”, the skin. BugTracker.NET’s logs and appearance is easy to change.
Do you have experience with both FogBugz and BugTracker.NET? I’d be interested to read your comments.