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 actionable; 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 practice; 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, 36 and a bug related to date formatting caused a large-scale Twitter outage. 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: key insights ˽ 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.