I do a lot of work with and around static analysis tools. Obviously, I write for this blog. I also have a consulting practice that includes detailed codebase and team fact-finding missions, and I have employed static analysis aplenty when I’ve had run of the mill architect gigs. Doing all of this, I’ve noticed that the practice gets a rap of being just for techies.
Beyond that even, people seem to perceive static analysis as the province of the uber-techie: architects, experts, and code statistics nerds. Developing software is for people with bachelors’ degrees in programming, but static analysis is PhD-level stuff. Static analysis nerds go off, dream up metrics, and roll them out for measurement of developers and codebases.
This characterization makes me sad — doubly so when I see something like test coverage or cyclomatic complexity being used as a cudgel to bonk programmers into certain, predictable behaviors. At its core, static analysis is not about standards compliance or behavior modification, though it can be used for those things. Static analysis is about something far more fundamental: furnishing data and information about the codebase (without running the code). And wanting information about the code is clearly something everyone on or around the team is interested in.
To drive this point home, I’d like to cite some examples of less commonly known value propositions for static analysis within a software group. Granted, all of these require a more indirect route than “install the tool, see what warnings pop up,” but they’re all there for the realizing, if you’re so inclined. One of the main reasons that static analysis can be so powerful is scale — tools can analyze 10 million lines of code in minutes, whereas a human would need months.
Dispute Resolution
One of the most “human element” type of benefits that I’ve seen for static analysis can come in the form of dispute resolution. If two people or two camps of people on a team are at odds over some particular practice or style of coding, static analysis tools can serve as mute, disinterested arbitrators. Should you avoid the singleton design pattern, or is it the greatest thing since sliced bread? If you’re at a log jam on this one, perhaps you can defer to NDepend’s “avoid the singleton pattern” warning that comes out of the box.
Please note that I am not suggesting that you should blindly follow the advice of a tool, nor that the tools are infallible. The purpose of the arbitration process is to offer a way for a credible source to settle disputes, and static analysis tools can serve in this capacity, at least for some issues.
Help with Morale
This may sound strange at first, but static analysis tools can actually be a source of morale for some teams. To understand how, consider the wisdom of the aphorism, “sunlight is the best antiseptic,” meaning that just revealing a problem makes its solution more likely. A software group may be struggling with all sorts of problems that are not common knowledge, but you can bet the developers understand and live them, even if not explicitly. For instance, consider a codebase with crippling and bad technical debt.
The mere presence of static analysis tools will serve to indicate two things to the development group: the business is aware of the problems and the business is willing to spend time and money on fixing them. That alone can be a surprisingly large morale boost for a team in a rut.
Definition of Department or Team Goals
With such tooling in place, the next major benefit I’ll talk about comes from using the tooling to define goals. This is important and not to be confused with letting tool compliance actually be your goal. I’m not talking about downloading a tool that says you have too many lines of code per method and then adopting “make the warning go away” as your goal (there’s nothing wrong with this, per se — it’s just not what I’m talking about here).
Instead, use the tools to explore your code, looking for themes and common problems. Enlist team members to talk anecdotally about issues that they have and what holds up the development process. Bring these two approaches together and use the static analysis tooling to gather data about problems and then propose solutions — solutions that are measurable.
I’ve heard it said that if you want to improve, the first step is figuring out what to measure. That’s what I’m talking about here — use the static analysis tooling to help you figure out what to measure and then to measure it.
Validate or Refute Business Hypotheses
Moving away from a team-focused benefits, we can also talk about the business as a whole. One of the main communication difficulties with software in general, is the unavoidable boundary between the people writing the software and everyone else. That delivery team understands the reality of the code at a nuts and bolts level, but everyone outside of the delivery team understands the code only through anecdotes (“oh, man, we can’t touch the invoicing module because it’s terrible legacy code!”) or downstream qualitative outcomes (“this release must be a bad one because we’re getting more complaints than usual.”)
Static analysis tooling can bridge this gap to an extent, and furnish data to interested parties outside of the delivery team. I cannot understate the importance of this capability. It allows the formation of a hypothesis like, “I think the team writes better code when they aren’t logging significant overtime” and then to empirically compare code written during lulls and rushes for certain properties. That is powerful!
Predict Business Outcomes
If you’re willing to continue in the same vein and to get a little bit more speculative, you can start to make predictions. After all, this is classic scientific method stuff. In the last part, I mentioned hypotheses confirmation or refutation, but you need hypotheses to do that in the first place. And while a hypotheses and a prediction are not the same, if you get good enough at formulating and verifying hypotheses, you start to develop a better prediction framework.
To get a little more concrete about it, consider a situation where you run experiments correlating properties of different codebases in your portfolio with each application’s defect rate. If you find a strong correlation between global state and high defects, it might be reasonable to predict a lower defect rate for a future release that involved no global state.
Broader Thinking with Static Analysis
These are just some benefits that occur to me off of the top of my head. No doubt other static analysis veterans could think of plenty of additional uses besides. And you’ll notice that nothing mentioned here includes anything about compiler design, logic theory, or anything else intimidating.
Static analysis is a topic that delves into the highly technical, to be sure. Analyzing source code for patterns and predictors is not for the faint of heart, to be sure. But remember that at the end of the day, it can be used for all sorts of purposes, highly technical and highly approachable. After all, static analysis is really about producing data.
