James from AccuRev: You want answers?

Tom the CC User: I think I’m entitled to them.

James from AccuRev: You want answers?!

Tom the CC User: I want the truth.

James from AccuRev: You can’t handle the truth! Tom, we live in a world that has complex software. And that software is going to be coded by men with computers. Who’s gonna do it? You? You, Tom with your CC? We at AccuRev have a greater responsibility than you can possibly fathom. You weep for CVS and you curse SVN. You have that luxury. You have the luxury of not knowing what we know: That the AccuRev SCM tool, while special and unique, probably saved jobs. And AccuRev’s existence, while grotesque and incomprehensible to you, saves jobs. You don’t want the truth. Because deep down, in places you don’t talk about at tradeshows, you want us for your source code. You need us for your source code. AccuRev uses words like Keep, Promote, Update…we use these words as the backbone to a life spent managing source code. You use ‘em as a punchline. We have neither the time nor the inclination to explain ourselves to a man who drinks coffee and programs under the blanket of the code management we provide, then questions the manner in which we provide it. We’d prefer you just send us a P.O. and went on your way. Otherwise, I suggest you pick up an IDE and start programming. Either way, I don’t give a damn what you think you’re entitled to.

James from AccuRev: Did you order something besides AccuRev?

Tom the CC User: I did the job that the IBM bigot made me do.

James from AccuRev: Did you order the CC?

Tom the CC User: You’re damn right I did!!!

James from AccuRev: All you did was weaken a company today, Tom. That’s all you did. You put software projects in danger. Sweet dreams, son.

by Damon Poole

There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost. The problem of creating a defect inventory is completely orthogonal to the user of a defect tracking system.

A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from an issue tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.