One could argue that static analysis is actually fairly pervasive, particularly among companies who produce shipped software as their business and where quality and security is critical. If you count the organizations who use static analysis (and ignore some overlap) it would number well into the thousands. In addition, opensource tools like Findbugs and others have a decent following as do free static analysis tools bundled with IDE's and compilers. And yet, static analysis still has a way to go before it becomes a part of the standard toolchain that most every organization uses. Getting static analysis used effectively within the organization is a second order challenge once an organization decides to use static analysis.
I will attempt to summarize some of the interesting points that were surfaced in the sometimes heated discussion. Some I agree with and some I don't.
- Static analysis tools can be noisy - producing false positives. Does static analysis consistently produce real issues? Are the issues reported comprehensible and actionable?
- Static analysis tools were overhyped many years ago causing expectations to be set too high.
- Developers are protective of their code and don't like a tool poking at their "treasured creations".
- Static analysis vendors are still small or medium-sized and therefore don't yet have the marketing budgets to communicate to the broad market. HP and IBM's recent acquisitions of Fortify Software and Ounce Labs may change this at least in the security space.
- Static analysis is often viewed as as an additional step after a "successful build" when it should be release criteria for passing or failure.
- The term "static analysis" is boring and doesn't reflect the sophistication of the analysis
- A multitude of defects are reported and developers don't know where to start or how to create a real process that addresses the issues
- Ignorance of the value of tools in the software development process. The all too frequent way that managers and senior staff treat software as an art that cannot be improved through better process and tools.
- Need a clearer demonstration of the value static analysis provides (the benefit minus the costs).
Andy,
ReplyDeleteI see two main problems:
1. Simplicity
2. Price
The first one is the most damaging to the industry. To adopt and install a great static analysis tool requires a lot of time and effort - it is not something you just "have" there as part of the build environment. Setting it up can easily take several days and the end result might even need a kind of an "admin" to deal with.
Instead of being dead-simple like using a comparison tool (think Beyond Compare), it is more like installing and maintaining source control bloatware (think Clear Case).
As for pricing - the best tools are very expensive, which makes it hard for R&D manager to make the purchase decision without the need to try and explain the value of the tool to higher management.
Tsahi
Tsahi, I think you make a very valid point. In order for static analysis to understand the code properly it has to parse the code correctly. With numerous interpretations of C and C++ and the ad hoc way that most software is built you run into complications that cause complexity when integrating these products. In addition, one-size has to fit all from a tiny driver to a complex server product and so customization is almost always in order to improve the results.
ReplyDelete