Why should my team use a bug tracker?

[kfreezen]

Hello,

I am working with a man that requires proof that something is better before he'll jump on the bandwagon, and so I require some help so I can convince him that bug trackers are a good thing.

As the subject indicates, we do not use a bug tracker, as such, currently. Instead we are fitting hitask to the job of both task tracking and bug tracking. One reason that he doesn't want to use another tool for bug tracking is "fragmentation", or, to put it another way, he doesn't want 3 to 4 different tools to do project management, but instead wants 1.

So right now, we use hitask and are giving each task a number, as a "compromise" that I suggested, but the more I think about it, the more it seems like the wrong way to do things.

So far, reasons (some may be fairly minor) to use a bug tracker include:

1. None of this manual issue number tracking that we are doing currently.
2. Users can actually come and enter bug reports on their own (not that our target market is computer-literate enough to do that), whereas hitask is pretty much only for teams to keep track of tasks.
3. Bug trackers can keep track of when a bug was fixed, how it was fixed, or even why it was not fixed, if the case may be.

He also said that he sees these projects with hundreds of open issues in their bug trackers, and that is also a reason why he doesn't want to use a bug tracker.

So now that I've typed my scattered thoughts on the matter, I would love to hear your opinions on bug trackers and/or task tracking, and what you have done, how it's worked for you, why it's worked for you, and why we should do it that way. Maybe my opinion is wrong, too?

Thanks,

kfreezen

[alexfru]

If/when your code becomes big and important, it'll be useful to know that certain bugs exist in certain versions of the product.

Support will use the info and know whether the bug is fixed or not and if it won't be fixed at all (AKA "by design" or whatever marvelous excuse you might have) and won't come bugging you with questions "Hey, the customer says X doesn't do Y. Can you tell me something about it?" every time. And the support won't need to create their own tracker from the scratch, they'll use yours to create new bugs (after seeing there are no obvious duplicates) or they'll be able to link to your bugs and they will get workaround info from your bugs (or maybe even contribute some).

Also, it'll give the developers and management an idea of problematic places (they can see types of bugs, bug count, etc).

If your team is just two people and you're doing something small, simple and throw-away-ish, you probably don't need a bug tracker. But even then, if you have a long break from the project, a bugtracker and a source control will prove useful as they'll help you remember what's been done and how and what still needs to be done. And that, of course, if you write proper descriptions of the commits and bugs with detailed reproduction steps.

Another important thing to consider is that people come and go. Bug info must not live only in people's heads, it must be shared and must not get lost when somebody leaves.

A bugtracker in Microsoft Windows was extremely useful. That's the scale where you absolutely cannot have none.

[embryo]

So far, reasons (some may be fairly minor) to use a bug tracker include...

Any project has a goal and a driver. If you are such driver - it is completely your responsibility to track issues and manage code quality. Why half of your team must think about your responsibility? It is boring and useless for them. That's why the project organisation is completely up to you. If you want a bug tracker - just use it, but do not order another half of your team to use it too. Of course, if you pay for some job then you can ask anything you want, but in a situation when there is a pure voluntary team it is not a good idea to insist on some project management requirements. If you see no wish to participate - may be it is better to stop insulting your partner.

And now about your part - if you see some benefits of managed information - just use corresponding tools, do what you want and get some success. After the success is with you - it is possible to convince other developers to follow you with the help of your success story. But be careful to distinguish between your success and other team member success. If you feel your project is in manageable state with all the tools you are using, it still doesn't mean that such feeling is something important for your team members. They just work for their goals and feel comfortable with what they have - why they should bother about project management? And if you feel that your team lacks some efforts in the project management area - may be the team is not consists of project mangers only? Somebody should write code, it is already a great contribution. Do you want more? Then it is up to you how to convince your team to work harder. If the team is voluntary then it is not always possible to convince it's members.

It is possible to have manageable project state with such means as emails or instant messaging with addition of some information organization tools on your side. For a team of two persons it is the best solution, as far as I can see.

[kfreezen]

To alexfru:

Thanks. I definitely agree that bug trackers are useful for large projects. The fact about support, IMHO, is enough to make any person doing any sort of commercial project use a bug tracker.

To embryo:

There is a problem, and that is that I am not "team-lead", or "project manager". My personal preference would be to use a bug tracker. I did like your suggestion about using the bug tracker for myself, but he needs to be on the bandwagon for us to use it for support.

[bluemoon]

or, to put it another way, he doesn't want 3 to 4 different tools to do project management, but instead wants 1.

You have only used half the feature for bug tracker.

If you open for public (or clients) to fire up bug report, you definitely want an isolation from your PM/gantt schedule instead of 1.

[embryo]

but he needs to be on the bandwagon for us to use it for support.

So, you can show your partner the benefits of improved support. And also it is important to understand, that the same benefits can be achieved in some other way and such way can be elaborated during team work. It means if your partner refuses to work as you see it, then you can ask him about another way of achieving the same benefits. It's all about team communication.