Who's Really In Charge Now?

Static analysis is fast becoming a standard part of every software development effort. Companies ranging from medical devices companies to Internet ecommerce vendors to car manufacturers to network equipment providers are purchasing static analysis solutions on the promise that finding defects sooner in their development process will save them time, money and embarrassment. The concept sells well at the developer and management levels because it makes sense.

And, static analysis tools are good these days. They aren't perfect, but with the right usage they provide a good bang for the buck. I stress the word "usage". Many companies buy the tool. The vast majority install the tool but a surprisingly high number don't get past running the tool even a couple of times. The product sits on the shelf.

There are many reasons why this occurs but the one we'll explore today is ownership. Someone has to own the tool and what happens to the results reported by the tool. Technical ownership is fairly straightforward. Static analysis tools are usually owned the tools group, who is responsible for setting up the software development infrastructure. They set up the factory floor, making sure that the engineers have all the tools they need to be efficient and effective. Automation plays a key role, helping to scale benefits across an entire team. However, unless the proper organizational and process infrastructure is in place, they are likely doomed to failure.

The purview of the tools group varies but does not include setting up new processes in isolation from the software development team. Oftentimes static tools are thrust on the tools group. The tools group then sets it up with the only goal of offering it as a voluntary service to the software development team. What ends up happening is a static analysis tool that is used by only a few enterprising software developers who believe in the value of tools and of software quality. The tools group is powerless to force more developers to use the tool and only a fraction of the potential value of the tool is realized.

Tools groups can lower the cost of usage by making it as simple as possible to use, by integrating the tools within their development process more effectively and by providing training, support and mentorship to developers. Tools groups also can take responsibility for tuning the analysis to make sure the results are as relevant as possible. But while carrot approaches are important and necessary, it won't get everyone over. You need to foster experts within the organization who can establish and defend the tool's worth. When you can set check-in, commit or release criteria that include static analysis, then you start getting the usage that will provide the payoffs that were paid for.

We've seen organizations that mandate that all new issues get addressed. Even false positives are "fixed" because if the code is confusing enough to fool a static tool, it will likely be confusing to the next person who must maintain the code. Others simply require that at least everything needs to be reviewed and it is up to the developers to determine whether they should fix them (the developers must document why they don't fix a problem). Others require specific classes of bugs to be fixed. The rules simply must match the business goals.

So even though tools groups are essential to the success of static analysis, they cannot be the only owner. Like any change within an organization, it requires executive sponsors, champions and a technical and organizational infrastructure to make it happen.