Stories about Software


Making Devs, Architects, and Managers Happy with the Static Analysis Tool

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  I use NDepend to drive my custom static analysis of .NET codebases — you should check it out.

Organizations come to possess static analysis tools 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 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 on their skill level and career.  In general, help them view this as an opportunity.

The Importance of Happiness

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.  Static analysis offers something for everyone in and around the team to like.  Help them understand that to get the most out of your investment.

Newest Most Voted
Inline Feedbacks
View all comments
5 years ago

As a developer, I preferred tools that were brought into the fold by other developers. ReSharper, for example, made me happy but also furious. Happy because I learned a lot from its suggestions. On of my favorites – invert if statement to reduce nesting. Made me furious since precompile times increased and sometimes VS would just crash with it installed. Likely it was that year’s version and things have improved.

That tool was introduced to the team by a developer. Gives me a great idea for a blog post about organizational structures.

Noah Sherrill
5 years ago

I have benefitted significantly from using static analysis tools as a developer. Some flaws almost always seem to slip past human eyes even with reviews, and automated tools can sometimes catch them. There are two problems with them though that I’ve encountered. One problem arises when people get too attached to the tool’s feedback. Yes, static analysis tools provide valuable information, but they are not 100% correct 100% of the time, so it is important to know when to go with your better judgement in lieu of what the tool is telling you to do. This is why nearly all… Read more »