How I Do Bug Tracking....and Maybe a New Product?

A recent post by Joel talked about how a customer of FogBugz went through a great deal of effort to get FogBugz working as a Help Desk tool. This thread revealed others are doing essentially the same thing.

As someone who started his IT career out by working at Help Desks, I am baffled how or why people are doing this (mixing bugs in with Help Desk tickets) without going nuts. But I am kind of an organizational freak. It seems like most users of FogBugz are also using it for Project Management, mixing feature requests in with bugs too, which makes OCD Phil weep.

That's part of the reason I have not purchased FogBugz (in addition to a couple of other issues I have with it). I just need different organization. And also, I kind of have my own home built bug tracking system I created a few years ago, which over time has morphed into a combination of FogBugz, SalesForce, Microsoft's beta testing system, and Campaign Monitor.



When I was learning ASP.NET for the first time, I needed some kind of non-important application to learn in. So I decided to create a bug tracker, since the popular systems at the time were not very usable in my opinion (BugZilla being the big one). It's always my sandbox for new technologies. When AJAX, or .NET 2.0 came out, this is where I would learn it, test it, etc...

What's so different about my Bug Tracker? Well, for one thing, it completely separates feature requests from bugs. Feature requests have their own world of properties, such as release dates, versions, files touched, etc.. Bugs need to be more interactive. There is usually lots of back and forth about a Bug, and it needs to disappear off my radar quickly. A Feature basically just sits there until I decide if I will implement it or not. The metrics for features and bugs also need to be completely different. In addition, not all the requests you get are actually bugs. Sometimes people just have a question, and sometimes there is more of a task ("Convert Bob's customer file"), so my bug tracker separates all those categories as well.

When I started SearTech, customer contacts became a lot more important. So I created a basic CRM, that also links in with the bug and feature trackers, so you can see from a customer's record how many bugs and which features they are reporting. When I started beta testing, I needed a way to gather feedback from people. I don't want customers seeing my internal bug tracker and feature tracker, so I created a way to make some of these public facing, and allow people to vote for their requests. This helps me prioritize them. I then needed a way to send out mass emails from contacts in my internal CRM, so I then created a system that personalizes emails to people, and tracks that activity.

When I created the first version of the bug tracker, I stuck it up on my website to see if anyone was interested, of course I knew little about software marketing back then, so just a few random people who visited my website signed up. But now I am wondering if maybe other developers who think like me would be interested in the system I use internally? It's not really related in any way to my other products, but hey it's 90% developed for general use already. But I imagine the last thing the world needs is another bug tracker or CRM.