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.
Summarized Dashboards for Management
Since management has the simplest motivation, they have the simplest path to happiness. Create dashboards for them that contain relevant summary information and hide technical details. Having occupied a dev manager role myself, I can speak to the power of something like, “codebase health, at a glance.”
Let this be a dramatic oversimplification, if you want. Have it be a dramatic visual as simple as “green, yellow, or red,” if you want. From a dashboard like this, management wants reassurance that things are alright or a conversation starting point if not. As long as that dashboard stays green, they can think about other stuff. If it goes yellow or red, time for a tactical discussion.
Resist the impulse to give management a granular view. This encourages them to micromanage and creates an inappropriate level of abstraction. If management worries about unit test coverage or cyclomatic complexity, it operates at the wrong level of abstraction. Customize the tool to get them to the right level.
Extension of Review for Architects
With architects, you contend with a potentially even split between threat and empowerment. Socialize the tool as an agent of empowerment to tip the scales in that direction.
With architects as accepted technical leaders in the group, their buy-in matters. It represents the difference between competition with the tool and getting value from it. Thus it probably pays to acquaint them with it before a generalized rollout. But, beyond that, letting them know that they can tune and customize it is important.
Work with architects in the group to show them how to customize it, and demonstrate to them that it can be adjusted and used to reinforce their technical vision. Architects frequently feel the pain of unclosed feedback loops. They issue recommendations and create prototypes, but can’t always be in enough places at once to confirm that their vision has propagated. Show them that static analysis can help here.
Learning for Developers
Here, things get dicey. Developers have two layers of folks calling the shots above them in many organizations: management and architects. And I have just laid out how each of those roles likes to use the report-out functionality of static analysis tools to see how things are going. But all too easily, “see how things are going” becomes “punish/reward the developers.”
If the development team get a whiff of the tool being used toward that end, they will hate it, and they will subsequently game it. Once that happens, its effectiveness becomes hampered and no one is happy. So for a first step, you need to assure the development team that this is not the intended use.
From there, make sure to get input from the team on the analysis rules and implementation. Ensure that they think of the tool as something they use, rather than something being used on them.
And even beyond that, make sure they understand how to use it to their benefit. Make sure they have access and can run it on their own code, using whatever rulesets they like. Some of them may view this as a learning opportunity, enforcing even stricter rulesets on themselves. Or, perhaps they simply have an interest in seeing custom statistics about different parts of the codebase. Encourage this curiosity.
To really drive that home, you need to do more than make the tool available. You need to show the team how to use it and talk up its benefits. Help them understand that a tool inspecting their code means fewer emails about coding standards or code reviews where senior team members point out mistakes. Explain the benefits of it on their skill level and career. In general, help them view this as an opportunity.
The Importance of Happiness with a Static Analysis Tool
I’ve spent an entire post talking about this because it matters. To get the full value out of a tool, the organization needs to be happy with it and to view it as a valuable addition to what they do. Dump something on them unceremoniously and they will ignore it. Force something on them, and they will resent and game it. Show them how it helps them, and they will participate in using it to make things better.
With any new initiative, you will have enthusiastic early adopters, a bunch of neutral people, and some resistors. I don’t intend to claim that you’ll succeed in making everyone swoon — just that you should do your best to socialize and sell the tool. A Static analysis tool offers something for everyone in and around the team to like. Help them understand that to get the most out of your investment.