Static Analysis: Isn't This Supposed to Make my Life Easier?

Software developers have a tough job. They have to produce working, good quality code from scratch, under immense time pressure and often without a good specification to provide guidance. Project estimates are always optimistic which leaves the developer in a situation where they have to work twice as hard to deliver what had been promised. Rarely are developers able to write code to the level of quality that they want to write. There just isn't enough time in the day. Is it any wonder that software developers resist adding more things to do in their process?

Along comes static source code analysis. Most developers don't want to add an additional step in their already harried process to check bugs that were found by another program. Here are the typical rants we hear from software developers?

False positives!! Nothing hurts the credibility of the tool more than false positives. If a tool is more wrong than right, developers won't trust the tool and consider it a waste of time to use. For most static analysis tools, you spend more time reviewing defects than actually fixing them. Fix the analysis so that it reports less wrong reports. Have a team (inside or outside the company) weed out the bad stuff so the development team can focus on developing.

Blend it into the process!! Forcing developers to take extra steps "out-of-band" not only slows them down but also makes them forget to run it in the first place. Make it run automatically with each build. Make it automatically assign defects to developers. Make it easily create a bug tracking report. Notify the developers rather than request them to look for it. Make it easy for them to do their jobs. Make it so that you don't need any documentation.

Tuning!! Developers are already busy enough -- they don't want to add static analysis expert to their growing list of responsibilities. If the analysis falsely identifies an issue as a bug, there are usually steps that can be taken to improve the analysis so that it understands the code better. Requiring the engineer to learn the system to be able to modify a configuration, add rules, etc. is a waste of time. Asking them to write their own static analysis checks is an effort that is often wasted. Have a static analysis expert make it understand the codebase and have them write the checks that are needed to be productive.

Make it faster!! Waiting for builds is bad enough. Waiting for static analysis to finish can be a time sink especially if it's a requirement to check in "clean code." Have an expert optimize the performance of the system. Cut down the analysis so that it analyzes only the stuff that has been changed.

Truly getting adoption from developers is a tough challenge. If they don't see the value, they won't use it. Maximizing the benefit returned from using the tool is just as important as minimizing the cost of learning and operating the tool. The key to bringing value is to manage this equation so that maximum return is achieved at an individual developer level. You'll never get perfect adoption without creating some artificial requirements (like not allowing a release without addressing all bugs). However, you'll have to fight a lot fewer battles if you make your user base as happy as possible.