Reasons not to build your own bug tracking system [closed]

Answer 1

Most developers think that they have some unique powers that no one else has and therefore they can create a system that is unique in some way.

99% of them are wrong.

What are the chances that your company has employees in the 1%?

Answer 2

Most importantly, where will you submit the bugs for your bug tracker before it's finished?

But seriously. The tools already exist, there's no need to reinvent the wheel. Modifying tracking tools to add certain specific features is one thing (I've modified Trac before)... rewriting one is just silly.

The most important thing you can point out is that if all they want to do is add a couple of specialized reports, it doesn't require a ground-up solution. And besides, the LAST place "your homebrew solution" matters is for internal tools. Who cares what you're using internally if it's getting the job done as you need it?

Answer 3

First, against the arguments in favor of building your own:

Wanting to 'eat our own dog food' in terms of some internally built web framework

That of course raises the question why build your own web framework. Just like there are many worthy free bug trackers out there, there are many worthy frameworks too. I wonder whether your developers have their priorities straight? Who's doing the work that makes your company actual money?

OK, if they must build a framework, let it evolve organically from the process of building the actual software your business uses to make money.

Needing some highly specialised report, or the ability to tweak some feature in some allegedly unique way

As others have said, grab one of the many fine open source trackers and tweak it.

Believing that it isn't difficult to build a bug tracking system

Well, I wrote the first version of my BugTracker.NET in just a couple of weeks, starting with no prior C# knowledge. But now, 6 years and a couple thousand hours later, there's still a big list of undone feature requests, so it all depends on what you want a bug tracking system to do. How much email integration, source control integration, permissions, workflow, time tracking, schedule estimation, etc. A bug tracker can be a major, major application.

What arguments might you use to support buying an existing bug tracking system?

Don't need to buy.Too many good open source ones: Trac, Mantis_Bug_Tracker, my own BugTracker.NET, to name a few.

In particular, what features sound easy but turn out hard to implement, or are difficult and important but often overlooked?

If you are creating it just for yourselves, then you can take a lot of shortcuts, because you can hard-wire things. If you are building it for lots of different users, in lots of different scenarios, then it's the support for configurability that is hard. Configurable workflow, custom fields, and permissions.

I think two features that a good bug tracker must have, that both FogBugz and BugTracker.NET have, are 1) integration of both incoming and outgoing email, so that the entire conversation about a bug lives with the bug and not in a separate email thread, and 2) a utility for turning a screenshot into a bug post with a just a couple of clicks.

Answer 4

Your discussions will start with what consitutes a bug and evolve into what workflow to apply and end up with a massive argument about how to manage software engineering projects. Do you really want that? :-) Nah, thought not - go and buy one!

Answer 5

We've done this... a few times. The only reason we built our own is because it was five years ago and there weren't very many good alternatives. but now there are tons of alternatives. The main thing we learned in building our own tool is that you will spend a lot of time working on it. And that is time you could be billing for your time. It makes a lot more sense, as a small business, to pay the monthly fee which you can easily recoup with one or two billable hours, than to spend all that time rolling your own. Sure, you'll have to make some concessions, but you'll be far better off in the long run.

As for us, we decided to make our application available for other developers. Check it out at http://www.myintervals.com

Answer 6

Because Trac exists.

And because you'll have to train new staff on your bespoke software when they'll likely have experience in other systems which you can build on rather than throw away.