John Ruberto, Intuit, Inc.
This paper tells the story of how our organization introduced static analysis into its software development process. The static analysis process automatically finds bugs, assigns them to the engineer that most likely introduced the bug, and then automatically verifies the fix.
This project began two years ago, when we started recording the root cause of bugs that were fixed. Once we had several hundred bugs analyzed, we found that the largest number of bugs was caused by coding errors. The good news, there are many best practices in industry to improve code quality. One survey of software quality practices (Jones 2011) shows that three practices, taken together, are capable of removing 97% of the defects. Those three practices are code review, static analysis, and unit testing.
Our organization already had healthy processes for code review and unit testing, but we had spotty history with static analysis. So, we took a fresh look at static analysis. When engineering the process for static analysis, we took care to avoid some of the issues of the past; namely false positives, excessive effort required to manage the bug list (triage false positives, manage assignments, etc.), and the demotivation of analyzing a large backlog of defects.
When we designed the new process, we decided to focus on automating the bug identification, assignment, and retest processes – eliminating a lot of the effort that got in the way of previous attempts. We also focused on keeping new code clean, which is much easier to justify than clearing old bugs from the backlog. The process also was designed to provide fast feedback, directly to the developer that created the bug.
Paying attention to new bugs has resulted in high levels of adoption by the developers, as compared to focus on backlog bugs. The engineers are fixing the new bugs that come in, plus have made a significant dent in the backlog.
John Ruberto, 2012 Technical Paper, Abstract, Paper
