Getting Buy-In For Static Analysis From Management.

I recently read an interesting article (8-Ways To Get Buy In From Management) on how to get buy-in from IT Management.  While the document is mostly focused on IT related activities, there are some valuable lessons that can be learned for any technical undertaking within an organization.  In this entry, we discuss some of the issues focused on static source code analysis.

1. Learn what management values. 

Software development management has a different set of concerns than most individual contributors have.  Clearly there should be alignment between management and worker-bees but that is too often not the case.  Static source code analysis will help you find bugs so that developers can fix them early in the development process.  From management's perspective, static analysis is almost a no-brainer. Caper Jones' estimates that static analysis can have a defect removal efficiency that can top 95% (presumably in a well configured, effective system and process). Other ways to describe the benefits include:

• Fewer defects and vulnerabilities in the field, meaning lowered support costs, fewer patches and better customer satisfaction
• Increased developer productivity
• Lower risk of late releases

Particularly for technology companies, arming developers with good tools so that they increase their effectiveness is a must.  How management couches the benefits is industry and company dependent.

2. Propose projects in management terms, not technical terms.

The benefits in #1 are real, but how tangible are they?  The more the benefits can be quantified, the easier it is to make a decision whether to institute static analysis or not.  A convenient way to break down benefits is to look at increases in opportunities, lowering of costs and reduction in risk.  Static analysis typically does not increase opportunities directly but an argument can be made that any reduction in development time enables more value-added features to be built.  Lowered costs are definitely significant.  Lowered support costs (in technical support, developer support (patches, etc.)) as well as increased productivity can be estimated.  Many companies use automated source code analysis to find problems quickly in an fast-paced Agile environment.  This enables increased throughput overall.  Reduction in risk can take many forms - the risk of late release, the risk of poor quality, the risk of lowered customer satisfaction, the risk of failing compliance etc.

3. Show management case studies and examples that support your point for cost savings or revenue enhancement.

Certainly leverage the vendor.  While they are not impartial, they often have good case studies.  References are also very important.  A lot of companies are using static analysis so leverage your contacts.  Better always to do backdoor references so you can get a balanced view.  People seem happy to discuss their experiences.

4. Find ways to minimize the project's expense.

While reducing license cost is a subject better left for closed door negotiations, there are ways to maximize the benefit you get from static analysis tools.  Make sure you take the time to tune it for your needs, integrate it into your process (both technically and organizationally) and try to tie metrics of value to release criteria.   Another way to get more value is to use the tool's extensibility capabilities to build your own custom checkers so that you leverage the analysis engine and the place in the workflow.  Wouldn't it be great to find and fix additional problems, violations in coding standards and more borrowing from what you are already doing.  When more people use the tool, more value is derived.  To get more people to use the tool, make it super easy to use, make the results as relevant as possible and make it clear as possible what is expected of all participants.

5. If your department's IT budget isn’t big enough, get help from another department.

A lot of folks can benefit from static analysis.  We've seen static analysis budgets come from not only the development organization but also from quality assurance, central tools, security groups and even governance organizations.  While they are not users, they can clearly benefit from the results and may help fund its usage.  Static analysis can also come from other overarching budgets such as from a quality and security initiative or projects related to moving to Agile / continuous integration and software development infrastructure automation.

6. Break up the project into easy-to-swallow pieces.

Breaking up projects into pieces not only makes it easier to swallow, it reduces risk.  As you see success in the early projects, it gives you knowledge (and confidence) to continue with the other phases of the project.  Start with a pilot group and see how that goes.  Set clear metrics for what is considered success for that pilot and work to meet it.  You'll learn significantly from the project to help you make better decisions down the line.  Use of static analysis as an integral part of a software development process is relatively new and thus haven't been ingrained into the DNA of most people and organizations.  That's changing but we're not quite there yet.

7. Look for ways to outsource part of the project.

This advice may be a bit self-serving, but I will mention that it never ceases to amaze me how many companies opt to do everything in-house.  The short term benefit from doing this is that organizations build some expertise in-house while not incrementally add budget.  But, they rarely get a best practices implementation. In addition, they have to give up some opportunity cost of having that developer take on a nonstrategic project versus something more relevant to the goals of the company.  In addition, by doing it all in-house it often takes a lot longer for them to get it done.  All too often, we see engineers struggle to do it in-house only to never really do a good job, never complete it and waste significant amounts of time doing so.   Outsource for expertise, outsource for opportunity cost, outsource to save a considerable amount of time.

8. Pick your battles carefully.

Static tools are not cheap -- not only to buy but also to effectively put into one processes.  The evaluation process for many static tools give you a good sense for what it can do for you so take full advantage of it.  If you need to, start small.  De-risk the project as best you can through prototypes and smaller rollouts.  Bringing in static analysis does require a commitment but pays off big-time when done correctly.  By its very nature, static analysis is proactive.  If you don't get funding the first time around, it shouldn't take long for the next emergency to make the situation more "favorable"for bringing in tools to more efficiently improve quality and security.