Commercializing academic research is not easy. When a company is up and running, people rarely take the time to reflect and report on their experiences for the benefit of others. Fortunately, Coverity staff members have done so, sharing anecdotes and recounting lessons learned from the commercialization of their static analysis tool.

A major lesson learned from this article is that working with build systems is difficult. The solution adopted by Coverity allows the build engineer to supply the build command as an argument to the Coverity tool.

Another major lesson learned is that you cannot check code you cannot parse. What matters are the compilers that customers use, and many compilers diverge in the code they accept and the extensions they provide. The paper’s only table lists 18 different C/C++ compilers that Coverity supports. The table also shows the number of lines of transformer code written by Coverity staff to turn the personal language of each compiler into something that can be accepted by the Edison Design Group’s parser for C/C++, the de facto industry standard.

Yet another major lesson learned is that more analysis is not necessarily good. The authors found that complex static analyses typically lead to complex explanations, which can get ignored, misunderstood, or, worse, labeled as false positives by developers.

The article fails to discuss how individual developers can make use of static analyses prior to merging their code for build purposes. Despite this criticism, I strongly recommend this article to computer science academics and industrial software development teams.