How to Add Static Analysis to Your Development Process

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.

If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

What is Static Analysis (Briefly)?

You can read up in great detail if you want, but I’ll summarize by saying that static analysis is analysis performed on a codebase without actually executing the resultant compiled or interpreted code.  Most commonly, this involves some kind of application (e.g. NDepend) that takes your source code files as input and produces interesting output by running various analyses on the code in question.

Let’s take a dead simple example.  Maybe I write a static analysis tool that simply looks through your code for the literal string “while(true)” and, if it finds it, dumps, “ruh-roh” to the console.  I’m probably not going to have investors banging down my door, but I have, technically, written a static analysis utility.

How This Fits

Let’s assume that you’ve gotten your hands on something a little more useful than my example.  What does this mean for development teams?  You have something that can analyze your code and give you feedback on it, but what can you do with it, exactly?
To an extent, that’s going to depend on what information, exactly, the tool doles out.  For simplicity’s sake, since this is an introductory explanation, let’s consider two very basic types of information often yielded by analysis tools.

• A warning that a given piece of code may be buggy.
• A warning that a given piece of code may be difficult to maintain.

Let’s again consider the mechanics.  Some static analysis tool takes your codebase as input, does its thing, and spits out a couple of lists.  One list points to a bunch of lines or methods in your codebase and says, “this one might be harboring a bug” and the other list points to a bunch of lines or methods and says “these are going to be hard for you to maintain.”

The Most Basic Approach

With this tool sitting on your development machine alongside your source code, the simplest thing you could do would be to execute it and take in the information it offers.  And that’s an excellent place to start.  The journey of 1,000 miles begins with a single step and all that.

Run it, see what it says, and then start some conversations.  Talk to others on your team about the tool and its output.  It will likely spark some interesting conversations ranging from, “yeah, that DoAllTheThings() method is terrible, but I guess I didn’t realize how terrible” to “I don’t agree with that at all!”  It tends to run the gamut.

But, you know what?  Whatever people say, it gets them talking, debating, and, most importantly, reasoning about the code.  It gets the team used to the idea that there’s more to code than simply “works or doesn’t.”  Code can be risky, and some code costs more than other code to own.

So start with the conversations, and let those around you get used to the water temperature.

Incorporate Static Analysis Into Code Review

Now that you’ve been having some spontaneous discussions about the code and people are acclimated to the tool, there’s a logical next step.  Introduce it into your code review process.  (Also, if you’re not doing code reviews, start doing code reviews.)

This will generally be preceded by some agreement upon which outputs of the analysis tool to abide by and heed, and there may be some tuning that needs to happen.  But the general idea is to add more rigor to the reasoning about code that happens.  It also has nice side effects, in the case of our two types of information.  It makes code review about catching potential defects, and it makes code review about keeping problematic code in the team’s consciousness as needing to be addressed.

Integrate Static Analysis into The Build

Once people are comfortable with the analysis tool and used to incorporating it into reviews, the next logical step is build integration.  This is where you integrate the analysis tool into your team’s build — the build automation that happens anytime someone delivers code to source control.  (Also, if you don’t have CI and build automation, start having CI and build automation).

You’ve been using the tool as an aid to perform code reviews, but now it’s time to automate and remove the human element, at least from the parts that can be automated.  So if “that method might be buggy” always triggers a rework following code review, stop worrying about it at code review time.  Instead, just make the build fail if that particular warning occurs.  Implementing this strategy, you can save code review time for less cut and dry, more discussion-oriented activities.

Your Mileage May Vary

What I’ve outlined here is an incredibly simple overview of how you might work static analysis into your team’s approach.  It is intended to make the concept a little more concrete if you’re wondering about how to implement it.  But I cannot possibly account for every nuance and unique situation.

Still, this should arm you with enough to get started.  And, hopefully, this will allow you to deliver in response to even the vaguest of hand-waving on the matter.