Friday, October 8, 2010

Why Have Static Analysis Tools Not Yet Hit the Mainstream

Over the past few weeks, there has been an interesting and lively discussion going on in a Linkedin group focused on static analysis.  The original question was along the lines of "Why hasn't static analysis penetrated the market further?"  The conversation has reached 97 comments and counting from developers, managers and vendors alike.

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).
Static analysis is growing particularly among organizations where quality issues and security vulnerabilities are most damaging but it will take a combination of improvements to the technology, changes to the attitude of development organizations and industry accepted best practices to take static analysis past the chasm towards the mainstream.  On the services front, we help many organizations overcome these issues through best practices in people/process/technology, mentoring, training, support and a multitude of other services.  When done right, organizations who take on static analysis do gain a competitive advantage.  These companies not only improve the quality and security of their products, they do so often with an overall productivity gain.  Invest in the right way and get some payback. Approach it with the wrong steps and a complacent attitude and then you are left to cross that chasm yourself.


  1. Andy,
    I 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.


  2. 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.