How do you get people to use a bug tracker?

Question

This is actually a question I should've asked a while ago(as in, I don't even work at this job) but I thought it to be an interesting question nonetheless.

Our team was basically just 1 developer(me!). The manager also developed sometimes, but was mostly just business. He thought we should have some sort of bug tracker, so we installed some open source tracker on our server. I initially did not use this bug tracker.

Then, another developer was hired. He doubled as a tester(sometimes) and it seemed like every morning(His shift was scheduled like 2 hours earlier than mine by preference) I'd come into work, he'd have about 2 pieces of paper full of bugs and possible bugs. I'd go through each item, mark them off as a fixed them, or wrote by-design, or fix later.

Anyway, then I'd come in another morning.. another list of bugs. About 6 of the 15 bugs listed were duplicates, or extremely related to bugs I'd previously said by-design or fix-later on.

So, I started using the bug tracker on our server. It wasn't hard to use(required only a bug title), but it wasn't great either. I told the other developer that he should start entering bugs there and I will check the bugs he submits when I come in. This way it'd be easier to track.

I come in the next morning, and lo and behold another piece of paper on my desk listed with bugs. At this point about 11 out of 13 listed bugs were duplicates. I didn't even bother writing on the paper. (this continued basically for about 4 months, until I was layed off)

TL;DR: What should I have done to convince this other developer to use the bug tracker?

Answer 1

If a bug is reported by any other means, ask the reporter to file it in the bug tracker. Don't work on or discuss it until it's filed in the system.

If this co-worker is in any way interested in doing good work or following best practices, it shouldn't be a hard sell. Even though the author sells bug tracking software, this article is right on.

Answer 2

Sounds like the second person wasn't your direct report so you couldn't exercise an influence based on a reporting hierarchy. This i what I would suggest:

Step 1: if this person is deaf to your suggestions and you don't understand why, just take him for a lunch or coffee and have a frank but good natured conversation. In a very simple terms, without being too technical or judgmental, explain why you want to see the change and how it would benefit both of you. Note that you felt resistance from him and inquire on the reasons. Knowing all the information and not having assumptions find a way to work together.

Step 2: optional. If there is still a resistance and you think it's unwarranted, talk to your boss and convince him or her on your way. Your boss can then mandate the change.

In the nutshell: friendly cheat-chat; if doesn't work - escalate :)

Answer 3

If you build it, they will come

I have been in your situation and found that the best strategy is to quietly start using it yourself. Keep them reporting bugs any way they want and spend some time entering them in the bug tracker of your choice. When done, send to the reported an e-mail with a link to the bug items in the tracker, you could also create an account for them and include in the e-mail a friendly reminder that they can look at the items from the comfort of their work stations. Start slow, do not expose the whole thing at once, first give them links to view items they submitted that morning, then start introducing reports on progress, view bugs submitted by others, view all bugs, edit comments etc. It may take a few weeks but if all goes well it is them that will come and ask you how they can enter bugs in the system by themselves.

Track everything, if duplicates were submitted, enter an update to the bug and state it was reported.. again and state by whom.

Track changes and progress of your investigations on the bugs and send them regular updates to the items they reported (many systems will do this automatically).

It is more work for you sure, but you get full benefits of the tracking system + if anything goes sour anywhere along the way you have written proof of what happened when and who was involved.

I have found that the most difficult aspects of using such a system when working alone is that I tend to not see the point any more and stop using it as thoroughly as I should. The first person you need to convince this tool is necessary is yourself. Convince others by making it easy to use and ensuring the tool provide them with added benefits. Get a feel of information they need and create reports automatically from the tool that they can see. By starting slowly you will also evaluate your need for the tool, sometimes it's just too much for what is needed. You will eventually see what exactly you require from the tool... progress reports, ass covering, code quality metrics, product history, documentation etc.

A bug tracker is a bi-dimensional communication tool, it can communicate across people and across time. Before you start collecting all this data or have others collect it for you you must convince them of the need for this data. In your manager's eye this collection comes with a cost and you must ensure that you can offset this cost by exposing the value of the data collected.

Build it, use it, improve it... eventually, if it's worth it, they will see the light.

Changes on any kind is always met with resistance. Who will you buy a car from ? The pushy salesman who force sell it to you by threats and scare tactics or the friendly guy who, with his sensible arguments, manage to convince you it's the best deal ever.