Organizations come to possess a static analysis tool in a variety of ways. In some cases, management decides on some kind of quality initiative and buys the tool to make it so. Or, perhaps some enterprising developers sold management on the tool and now, here it is. Maybe it came out from the architecture group’s budget.
But however the tool arrives, it will surprise people. In fact, it will probably surprise most people. And surprises in the corporate context can easily go over like a lead balloon. So the question becomes, “how do we make sure everyone feels happy with the new tool?”
A Question of Motivation
Before we can discuss what makes people happy, we need to look first at what motivates them. Not all folks in the org will share motivation — these will generally vary by role. The specific case of static analysis presents no exception to this general rule.
When it comes to static analysis, management has the simplest motivation. Managers lack the development team’s insights into the codebase. Instead, they perceive it only in terms of qualitative outcomes and lagging indicators. Static analysis offers them a unique opportunity to see leading indicators and plan for issues around code quality.
Architects tend to view static analysis tools as empowering for them, once they get over any initial discomfort. Frequently, they define patterns and practices for teams, and static analysis makes these much easier to enforce. Of course, the tool might also threaten the architects, should its guidance be at odds with their historical proclamations about developer practice.
For developers, complexity around motivation grows. They may share the architects’ feelings of threat, should the tool disagree with historical practice. But they may also feel empowered or vindicated, should it give them a voice for a minority opinion. The tool may also make them feel micromanaged if used to judge them, or empowered if it affords them the opportunity to learn.