Making the Case for Better Bugtracking Tools?

WeNeedBetterTools asks: "Help! I am trying to convince the leaders of my development organization that the quality of our bugtracking tool has a meaningful impact on the quality of products we produce. Right now, the tool we have is difficult to use because there is a high overhead to creating bugs, and they are very difficult to find in the system once they're reported. My main argument is that the easier the tool is to use, the more people will be motivated to enter bugs. My managers argue that if people aren't entering bugs, it's their own damn problem, and we ought to crack the whip until they always file every bug they possibly can. I need some solid references for my position. JoelOnSoftware has a great argument for making it simple to enter bugs, but he lacks credibility with my managers by virtue of the fact that he is also selling a bugtracking tool. Can anyone point me to any solid research on the relationship between the quality of bugtracking tool and the impact on product quality?"

Comments

so true

[oever]

there is a high overhead to creating bugs

I can confirm this. I introduced some bugs in my code today, but boy, am I tired right now. But hey, every bug counts.

Show some initiative

[Col. Klink (retired)]

Bugzilla's free (libre). Just install it. Managers always think everything's going to take a lot of time and they never foresee the benefits. On a Debian system, "apt-get bugzilla" and your done.

Most new technologies, Linux included, are installed in the enterprise by real people doing real work. Real Engineers(tm) don't wait around for the PHBs to realize a trend that's been going on for 6 years.

A Good Boss(tm) is one who sees that things work better now than before, and nothing more. If you expect more from a boss, you're delusional and you may as well start applying for management positions yourself.

And always remember: it's easier to get forgiveness than approval.

Re:Show some initiative

[babbage]

No, please don't use Bugzilla -- it's reputation far exceeds its actual quality. Bugzilla is an arcane, tightly bundled colledtion of hard to extend CGI scripts sitting on top of a bizarre MySQL schema. If it doesn't exactly meet your needs (i.e. you are not the Mozilla project), extending it can be a nightmare.

May I humbly suggest that you take a look at RT: Request Tracker instead. RT is a general purpose ticketing system, suitable not only for bug tracking, for for all kinds of organized message exchange within an organization (i.e. help desk, sales force tracking, some aspects of inventory management, etc). RT allows users to collaborate via a web interface, email, or the command line. By providing multiple interaction interfaces, RT encourages users to work with the system by communicating the way they would already, rather than working against them by forcing them to adapt to a wholly new system. If you don't like the web interface, feel free to change it. If it's still not enough, people can just use email instead -- just cc: your RT account on ticket related mails, and include the ticket number in the subject line. Hey presto, people can do almost what they were doing in the first place.

RT is written in clean, OO Perl making wise use of CPAN libraries instead of implementing everything from scratch. It will run on a variety of operating systems & databases (MySQL, PostgreSQL, Oracle). The system is well documented, easily extensible, and comes with a vibrant & supportive user community. It can even be integrated with things like pagers, so that the creation of critical tickets can send out a pager message to key personnel.

All in all, RT is a very nice, very well engineered system that IMO is far more suitable for most users than Bugzilla, for which the suitable scope is much more restricted. That's why RT is now being used in, among other places, Perl's bug tracker at rt.perl.org.

Disclaimer: My company uses RT, and I have met Jesse Vincent, RT maintainer, a handful of times, and even though I think it would be pretty cool if people switched to RT and bought support contracts from Jesse, I have nothing to gain if any of this happens. I just sincerely think that RT is better software than Bugzilla for almost all users, and would like to see development of the software continue to flourish and become accepted more widely. Spend a week messing around with RT and IMO you'll never want to go back to Bugzilla...

not enough info

[josephgrossberg]

Why don't your managers want to try something new? If it's price, tell them bugzilla is free, and is used by companies from Red Hat to Netscape. If it's a political issue, that's a whole 'nother story.

Also, why is there so much overhead? Entering a bug should be as simple as filling out a single HTML form. Is your UI too big and complicated? You can probably strip it down to the essentials, without discarding it entirely. Is it on more than one page? You can probably condense them into one form. Are the bugs stored in a database? You can write your own search page.

And if you said which bug software you're currently using, you could probably have gotten more specific and relevant tips on how to make the best use of it (change the configuration, prepopulate certain fields, roll your own modified templates, etc.).

Fight hard

[image]

Hi. I am the senior software architect for a rather large and well-known company doing business on the internet (~$1M/day in online revenue). One of the first things I did after taking this position, with the goal of turning the development team (100+ engineers) into a top-flight software house, was put a process in place to use a bug-tracking system not just for post-deployment defect control, but also during the development phase. Each task is tracked through a ticket and tied to a particular branch in our source control system. This creates a running log of not just the work itself, but also the thought that goes into the work.

While there was some resistance at first among developers and managers that had never done this before, over a few short months our code quality has improved and our production increased. In fact, the final case was made when comparing two teams of roughly equal size, one using the tracking system during development, one not. The one that was using it not only had fewer defects, but had written about twice as much code in the same time period. And the real benefit will come a year or two from now when we need to go back and triage a decision or issue long after the original engineers have moved around.

We happen to be using bugzilla and cvs as they are free, easy to modify to meet our needs, and familiar, but you could do this with just about any tool that allows you to track arbitrary issues.

Good luck -- and don't give up.