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

Answer 1

First, look at these Ohloh metrics:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

What do we learn from these numbers? We learn that building Yet Another Bug Tracker is a great way to waste resources!

So here are my reasons to build your own internal bug tracking system:

1. You need to neutralize all the bozocoders for a decade or two.
2. You need to flush some money to avoid budget reduction next year.

Otherwise don't.

Answer 2

There is a third option, neither buy nor build. There are piles of good free ones out there. For example:

• Bugzilla
• Trac

Rolling your own bug tracker for any use other than learning is not a good use of time.

Other links:

• Three free bug-tracking tools
• Comparison of issue tracking systems

Answer 3

Building on what other people have said, rather than just download a free / open source one. How about download it, then modify it entirely for your own needs? I know I've been required to do that in the past. I took an installation of Bugzilla and then modified it to support regression testing and test reporting (this was many years ago).

Don't reinvent the wheel unless you're convinced you can build a rounder wheel.

Answer 4

I'd say one of the biggest stumbling blocks would be agonising over the data model / workflow. I predict this will take a long time and involve many arguments about what should happen to a bug under certain circumstances, what really constitutes a bug, etc. Rather than spend months arguing to-and-fro, if you were to just roll out a pre-built system, most people will learn how to use it and make the best of it, no matter what decisions are already fixed. Choose something open-source, and you can always tweak it later if need be - that will be much quicker than rolling your own from scratch.

Answer 5

I would want to turn the question around. WHY on earth would you want to build your own?
If you need some extra fields, go with an existing package that can be modified.
Special report? Tap into the database and make it.

Believing that it isn't difficult? Try then. Spec it up, and see the list of features and hours grow. Then after the list is complete, try to find an existing package that can be modified before you implement your own.

In short, don't reinvent the wheel when another one just needs some tweaking to fit.

Answer 6

Don't write your own software just so you can "eat your own dog food". You're just creating more work, when you could probably purchase software that does the same thing (and better) for less time and money spent.