Another Tuning Story...

One customer that we worked with in the past has a medium sized codebase that handles financial-based transactions.  Their business deals with a lot of money and is highly regulated. Management has very high expectations that their software development team build their products with superior quality.  Not surprisingly they have turned to many modern techniques and technologies to keep up with the pace and scale of development.  They began using source code analysis a few years ago in order to detect and fix problems before release.

In their first run alone, the source code analysis tool reported over 20,000 potential defects.  They didn't know where to begin.  Even if it took 1 minute to go over each defect it would take over 40 business days to complete.  Realistically to query up the result, understand the defect report in the code, prioritize and document it briefly would take more on the order of 5-10 minutes per issue.  That's of course averaging the occasional really easy issue and really difficult issue.  At 7.5 minutes per issue that becomes 312 business days -- a significant investment by any standard.  Of course static analysis is one of the best ways to improve the systemic quality of your code as it is much less expensive to find and fix problems before release.

But there is a better way than using brute force to fix static analysis defects.  Tuning the analysis almost always results in significant improvements in the analysis quality, which means fewer false defects and more real defects.  After just a couple of days with this customer we knocked their queue down to about 9000 defects.  Actually, we knocked it down to about 8000 defects but then found an additional 1000 new defects that weren't being detected before.  The time savings, as you can imagine are large. The psychological effect was even better.  Although 9000 is still a mountain to climb, it's psychologically a lot better to hike up Kilimanjaro than scale Mount Everest.