On my current project (one developer, total of six months, one month left) I have from the very beginning been using the static analysis tool "FxCop". The tool is not Open Source, but freeware from Microsoft, so it is somewhat in between being commercial and non-commercial.

Until now I have experienced both benefits and drawbacks. FxCop actually catches real bugs, albeit not any that I commit very often. Until now it has raised a warning 3 times for one specific kind of error in my code: that I forgot to call Dispose() on a member variable implementing IDisposable. Giving me this warning have probably saved me about 3 hours of debugging.

One major drawback is that it takes quite some time to run FxCop (almost as much time as a recompile), so I will not run it on every compile, meaning that I sometimes forget to run it - that's why I know how long time it takes to debug a case of a forgotten call to Dispose()

The other major drawback is that FxCop will give me an awful lot of warnings about code that it finds suspicious; warnings that I consider to be just silly. In this project I have used some time to rewrite the code to prevent FxCop from giving warnings. Otherwise I could have annotated the code to make the tool suppress just these warnings for just these places in the code. I guess that I have used around 6 hours on the rewriting. And I still have around 10 warnings that I haven't yet taken time to eliminate.

In conclusion I must at this point say that FxCop does not seem to be of real benefit for me.
By Lars Thorup

Reading Lars' article Why Bugs should not be Tracked, and the following discussion on Joel on Software made me think quite a bit about my own view on bug tracking.

Most people in the software industry would probably agree that bugs are inevitable. But consider this -- If the rate at which bugs go into your bug tracking system is higher than the rate at which you are fixing them, you are inevitably up for trouble.

You can either prioritize the same bugs over and over, or close them with a "Won't fix" right away. Prioritizing the same bugs over and over doesn't seem to make much sense for something you are unlikely to fix, as long as the rate of incomming defects is not decreasing.

I am not saying there is something wrong with the bug tracking systems. What is wrong is that we have so many bugs that we need systems to track them and (re)priotize them. The reason I'm quite skeptical about tracking systems is because using them takes away focus from the underlying issue.

Reading the discussion on Joel, it seems that there are those who believe that the human race would not survive without bug tracking systems.

"I have 20 bugs comming in every week -- I need a bug tracking system!". Yes, then you certainly do. At least until you bring the defect rate down to 1 bug a week. You may feel you are in need of a bug tracking system, but what I think you really need is to ask yourself: Why are we releasing so many defects?

I like to tell myself that everytime a bug is found outside our lab, my team is responsible for wasting the customer's time.

If you have a lot of existing defects in your bug tracking system consider the following experiment:

Say you have 300 open bugs in your tracking system. You estimate that 200 of them can be considered important to your customers. How long with it take to fix these issues if you didn't work on anyhing else? Let's say 3 months. Now remove the 100 you won't fix anyway (They will show up later if they really are important)

Use a bug tracking system for the next 4 months only. This gives you 3 months to get the number of defects down to zero, as well as 1 month figure out how to get your defect rate down to one per week. If you can manage to do so your need of a tracking system should have changed.

I believe that if you can...

1. Reduce the rate at which you introduce bugs.
2. Choose to either fix or ignore the legacy bugs you already have.

...You will waste less time on "tracking" bugs, and in time your bug tracking system should become more or less superfluous.

By Sune Gynthersen