Editorial Note: I originally wrote this post for the NDepend blog. Check out the original here, at their site. While you’re there, take a look at the features of NDepend and download a trial, if you’re so inclined.
When software developer talk about static analysis, it’s often in the context of craft improvement. Ask most developers in a group about static analysis tools and you’ll get a range of responses, many of which will be fueled by some degree of passion, resulting from past experience. From here, the conversation will tend to dive into the weeds for any non-technical stakeholder that might be listening; if you’re not a programmer, you probably don’t have much of an opinion as to whether or not cyclomatic complexity of 5 is acceptable for a method.
As a result, static analysis tends to get pegged heavily as a purely a matter of shop. The topic tends to be pretty opaque to management because developers present it to them in terms of “this will make us better and the code better.” Management that trusts the developers will tend to agree to the purchase with a sentiment of, “okay, I’ll take your word for it.” Management that is more skeptical says, “maybe next year if our numbers are good.”
I find this to be a shame because it’s a lost opportunity, even when management agrees.
Static analysis most certainly is a way for developers to improve their craft and their codebases. But, in the hands of an architect or team lead that truly understands the business and works well with management, static analysis can be an excellent tool for managers, even if the use has to be a management-architect team effort.
How so? Well, there are a lot of ways, but the one I’d like to mention today is risk management. As the title would imply, managing risk tends to be the purview of people whose title is manager. Sure, the developers have responsibility for this, but their primary charter is to build stuff — management exists specifically to engage in planning activities, including the crucial concern of risk management.
How does this work? Well, I’ll show you, and I’ll do it by explaining the sort of highly technical things that static analysis could catch in highly non-technical and readable ways. These are all going to be operational risks — static analysis can’t help you if you’re building the wrong product or badly under-staffing your projects. But it can help you avoid landmines in your software. If you’re a manager, allow me, for the moment, to serve as your “business-savvy architect.”