Tools at Google
For a static analysis project to succeed,
developers must feel they benefit from
and enjoy using it.
BY CAITLIN SADOWSKI, EDWARD AFTANDILIAN, ALEX EAGLE,
LIAM MILLER-CUSHON, AND CIERA JASPAN
Not integrated. The tool is not integrated into the developer’s workflow or
takes too long to run;
Not actionable. The warnings are not
Not trustworthy. Users do not trust
the results due to, say, false positives;
Not manifest in practice. The reported bug is theoretically possible, but the
problem does not actually manifest in
SOFTWARE BUGS COST developers and software
companies a great deal of time and money. For example,
in 2014, a bug in a widely used SSL implementation
(“goto fail”) caused it to accept invalid SSL certificates,
and a bug related to date formatting caused a large-scale
23 Such bugs are often statically detectable
and are, in fact, obvious upon reading the code or
documentation yet still make it into production software.
Previous work has reported on experience applying
bug-detection tools to production software.
6, 3, 7, 29
Although there are many such success stories for
developers using static analysis tools, there are also
reasons engineers do not always use static analysis
tools or ignore their warnings,
6, 7, 26, 30 including:
˽ Static analysis authors should focus on
the developer and listen to their feedback.
˽ Careful developer workflow integration
is key for static analysis tool adoption.
˽ Static analysis tools can scale by
crowdsourcing analysis development.