The Google FindBugs fixit

Published 12 July 2010

Nathaniel Ayewah, William Pugh

Citations131

TL;DR

It is observed that even though most issues were flagged for fixing, few appeared to be causing any serious problems in production, which suggests that most interesting software quality problems were eventually found and fixed without FindBugs, but FindB Bugs could have found these problems early, when they are cheap to remediate.

Abstract

In May 2009, Google conducted a company wide FindBugs "fixit". Hundreds of engineers reviewed thousands of FindBugs warnings, and fixed or filed reports against many of them. In this paper, we discuss the lessons learned from this exercise, and analyze the resulting dataset, which contains data about how warnings in each bug pattern were classified. Significantly, we observed that even though most issues were flagged for fixing, few appeared to be causing any serious problems in production. This suggests that most interesting software quality problems were eventually found and fixed without FindBugs, but FindBugs could have found these problems early, when they are cheap to remediate. We compared this observation to bug trends observed in code snapshots from student projects.

Keywords

Computer Science

Finding bugs is easy

775 Citations2004David Hovemeyer, William Pugh

It is found that even well tested code written by experts contains a surprising number of obvious bugs and that simple automatic techniques can be effective at countering the impact of both ordinary mistakes and misunderstood language features.

Communications of the ACMA few billion lines of code later

624 Citations2010Al Bessey, Ken Block +8 more

IEEE SoftwareUsing Static Analysis to Find Bugs

504 Citations2008Nathaniel Ayewah, William Pugh +3 more

FindBugs evaluates what kinds of defects can be effectively detected with relatively simple techniques and helps developers understand how to incorporate such tools into software development.

Static analysis tools as early indicators of pre-release defect density

276 Citations2005Nachiappan Nagappan, Thomas Ball

An empirical approach is presented for the early prediction of pre-release defect density based on the defects found using static analysis tools and it is shown that there exists a strong positive correlation between the static analysis defect density and the pre- release defect density determined by testing.

Which warnings should I fix first?

203 Citations2007Sunghun Kim, Michael D. Ernst

A history-based warning prioritization algorithm is proposed by mining warning fix experience that is recorded in the software change history by improving warning precision to 17, 25, and 67% respectively.

A metric for software readability

175 Citations2008Raymond P.L. Buse, Westley Weimer

An automated readability measure is constructed and it is shown that this metric correlates strongly with two traditional measures of software quality, code changes and defect reports and suggests that comments are less important than simple blank lines to local judgments of readability.

Statistics in a Nutshell

172 Citations2008Sarah Boslaugh, Paul Watters

Statistics in a Nutshell gives you a solid understanding of statistics without being too simple, yet without the numbing complexity of most college texts.

ACM SIGCSE BulletinExperiences with marmoset

166 Citations2006Jaime Spacco, David Hovemeyer +4 more

Predicting accurate and actionable static analysis warnings

125 Citations2008Joseph R. Ruthruff, John Penix +3 more

Prioritizing Warning Categories by Analyzing Software History

85 Citations2007Sunghun Kim, Michael D. Ernst

This paper proposes a preliminary algorithm for warning category prioritizing by analyzing the software change history, and indicates that different warning categories have very different lifetimes.