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

Answer 1

Being a programmer working on an already critical (or least, important) task, should not let yourself deviate by trying to develop something that is already available in the market (open source or commercial).

You will now try to create a bug tracking system to keep track of the bug tracking system that you use to track bugs in your core development.

First: 1. Choose the platform your bug system would run on (Java, PHP, Windows, Linux etc.) 2. Try finding open source tools that are available (by open source, I mean both commercial and free tools) on the platform you chose 3. Spend minimum time to try to customize to your need. If possible, don't waste time in customising at all

For an enterprise development team, we started using JIRA. We wanted some extra reports, SSO login, etc. JIRA was capable of it, and we could extend it using the already available plugin. Since the code was given part of paid-support, we only spent minimal time on writing the custom plugin for login.

Answer 2

Not Invented Here syndrome!

Build your own bug tracker? Why not build your own mail client, project management tool, etc.

As Omer van Kloeten says elsewhere, pay now or pay later.

Answer 3

At this point, without a large new direction in bug tracking/ticketing, it would simply be re-inventing the wheel. Which seems to be what everyone else thinks, generally.

Answer 4

I agree with all the reasons NOT to. We tried for some time to use what's out there, and wound up writing our own anyway. Why? Mainly because most of them are too cumbersome to engage anyone but the technical people. We even tried basecamp (which, of course, isn't designed for this and failed in that regard).

We also came up with some unique functionality that worked great with our clients: a "report a bug" button that we scripted into code with one line of javascript. It allows our clients to open a small window, jot info in quickly and submit to the database.

But, it certainly took many hours to code; became a BIG pet project; lots of weekend time.

If you want to check it out: http://www.archerfishonline.com

Would love some feedback.

Answer 5

I would just say it's a matter of money - buying a finished product you know is good for you (and sometimes not even buying if it's free) is better than having to go and develop one on your own. It's a simple game of pay now vs. pay later.

Answer 6

Tell them, that's great, the company could do with saving some money for a while and will be happy to contribute the development tools whilst you work on this unpaid sabbatical. Anyone who wishes to take their annual leave instead to work on the project is free to do so.