Slashdot Mirror
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?"
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.
-- Don't Tase me, bro!
Sounds to me as a very very expensive way. THe way I always work is simply using Bugzilla (make it the homepage on all machines for all I care!) and have the bugmaster run through all issues at least once a day, he/she can than decide who's gonna get the bugs in order to fix em and also check for dupes. Bugzilla is by far easiest and cheapest to implement in any environment. It is free and webbased and moreover, it is very easy to customize it. If your management doesn't want to spend too much money on quality it is their problem, but keeping your work fun and somewhat easy is your own. So just implement a solution and after a couple of weeks show the improved results to management. Another thing to improve stuff is by implementing UnitTesting. Have developers write UnitTests before writing any code and run your unittests with every build (Contiuous Integration is Heaven for testers!!) If Unit tests fail, it is no use testing software by hand and you can start kicking developers around.
We're all out there, somewhere, waiting to happen.
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.
Hard to say what will motivate a manager, but in the case of the folks using the tools on a regular basis, it can be effective to talk to them about the way you imagine bug tracking should work, the benefits they get from those practices, and then talk about how your current tool supports or inhibits those practices.
The first two steps, practices and their benefits, are something I've done a little research on, and put together a set of Defect Tracking Patterns that discuss how to work and the benefits of those practices in context.
Maybe if you can convince enough of the folks to want to adopt good practices, and that the current tool does not work well for those, you'll have some leverage with THe Boss.