In the article, Testing with leverage, Part 1, author Brian Goetz compares and contrasts the software quality techiques of unit testing, code reviews, and static analysis. He suggests that the best return on investment will be realized by employing all three, and explains how to extend the static analysis tool FindBugs with a new bug detector. In situations where you can use this approach, creating a bug detector allows you to find all instances of a certain class of bugs simply by running the static analysis tool. The main idea behind this approach is that instead of simply fixing a bug when it is discovered, you fix it and try to find a way to prevent the entire class of bugs in the future.

Brian suggests that the main cost of static analysis is the time spent wading through false alarms—bugs that are reported, but which really aren't bugs. Each time you write a bug detector, of course, there will also be a cost. The payback, of course, is that you can find and fix many bugs before you ever run the program, bugs which may have been missed by other quality techniques, such as code reviews, unit testing, and plain old QA testing.

Have you used static analysis on your projects, and if so, what did you find was the most cost effective way to use it? Which tool or tools did you use? To what extent were false alarms a problem, and how did you manage them? And lastly, to what extent have you written your own bug detectors?