NDepend Blog

Improve your .NET code quality with NDepend

managing risk mouse

Managing Risk in your Project with Static Analysis

May 26, 2016 6 minutes read

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.”


In the realm of database applications, there is a concept known as “SQL Injection” that can be used against your application if the developers don’t take certain precautions with their database access.  A depressingly large number of shops are not really aware of this at all, and, worse, of those that are, a large percentage will rely essentially on the experience of the senior team members (read: tribal knowledge) to enforce this rule manually

For something as simple as “this is the canonical way to do database access so we don’t get broadsided by preventable exploits,” static analysis is a wonderful option.  There are solutions out there that can turn oversights like this into warnings or even errors that will hit the stop button before this ever makes it into your staging environment, let alone production.



Let’s say that you’re concerned about the privacy of your users’ data (maybe you have to contend with HIPAA).  To get a little more concrete, let’s say that your application stores sensitive, personally identifying information about your users, and you have to be very careful about who can see this information and how.  For example, there would be a shortlist of folks who can get emails about this information and those emails would need to be encrypted.

You can leverage static code analysis to flag potential risk-incurring mistakes that developers might be making along these lines if they aren’t savvy with privacy rules.  This may require some standardization of the code to accompany the analysis rules, but it is quite achievable.

Defect Detection

Static analysis is excellent at detecting certain, likely causes of defects.  I won’t go into the technical details, but such tools essentially keep a field guide of “known developer mistakes” and are smart enough to analyze the code and find likely culprits.

This is by no means bullet proof, but it can catch a surprisingly large cross section of problems before they can sneak into production.  And, the types of bugs that it prevents are often subtle ones that may not rear their heads until long after everyone has assumed the code is safe.

Feature Slowdown

This is a slightly different kind of risk than the others, in that it’s a broader-scoped operational risk.  The first three would all result in sudden, midnight phone calls that ratchet adrenaline production into overdrive.  This concern will happen as a slow boil, chipping away at the business and the group’s credibility.

Codebases tend toward entropy, so to speak, and over the course of time, you’ll find that it takes longer and longer to develop the same sorts of features.  This happens in the same way that a game of Jenga proceeds — the code gets more complex and more inscrutable, and so changing it becomes more perilous.  In some ways, this is a more existential risk than any of the others.

Static analysis tools serve as a canary in the coal mine here, allowing you to keep watch over your code for signs of this entropy.  This will take the form not of warnings, but of trend scores and composites that you monitor over time.  Static analysis can help you make sure your group can continue to respond to requests for functionality.


Your Automated Architect

If you notice a common thread here, it’s that you’re automating the oversight of your senior/knowledgeable people.  When I talked earlier about a successful pairing between the technical leadership and management, I didn’t simply mean that the two could talk and understand one another.  It’s more than that; it’s about eliminating the need for the tribal knowledge that I also mentioned.

The people who know not to email sensitive information and who know not to write the wrong kind of queries are valuable and they’ll help grow that skillset in others.  But they’re also human.  They get sick and take vacations.  They have long days and can’t get to all the code review requests in their inbox.  They quit the company to open up a boat rental business in Bermuda.   Static analysis tools don’t do any of these things.  They work 100% of the time within their scope.

So if you find yourself in a conversation about static analysis and technical folks are telling you about improving code quality and the like, ask them about how it might help with managing risk.  At the very least, you’ll give them something to consider for their pitch, and, with any luck, you’ll start a productive conversation about how you can all sleep better at night.



New Call-to-action