Deployed without the right support, static analysis tools can be undermined by employee resistance.

Getting employee buy-in for static analysis

on Nov 6, 12 • by Chris Bubinas • with No Comments

Deployed without the right support, static analysis tools can be undermined by employee resistance...

Home » Static Analysis » Getting employee buy-in for static analysis

The technical argument for static analysis tools is fairly clear: By automating the detection of bugs without exercising the source code, these tools increase productivity for the entire development team and reduce the headaches, costs and reputation damage associated with fixing issues following a release. Deployed without the right support, however, static analysis tools can be undermined by employee resistance.

According to Dr. Dobb’s writer Flash Sheridan, the key to generating value from such tools is ensuring employee buy-in, a process that must take place across several points of an organization. Source code analysis tools need to be supported by employees involved in testing, by managers responsible for delivering measurable results and by the coders themselves. With more employees on board, static analysis tools can deliver significantly more value.

Assigning responsibility
The first step to a successful static analysis deployment is ensuring that the motivations for investing in the tool are clear and communicated. The entire development team should be committed to improving the security and reliability of their product by fixing existing defects and preventing future ones, Sheridan suggested.

The responsibility for running such tools should be assigned in a way that ensures developers will ultimately be tasked with diving in to make difficult changes in the code. However, final oversight should still reside with quality assurance staff, Sheridan said.

Tangible results to save time
One of the biggest points of resistance with static analysis tools is that they can add more work for developers up front. Employees on tight deadlines are not likely to appreciate being handed a list of errors, and they may be particularly disinclined to actually fix these problems if they believe many to be false positives or false false positives. To overcome this assumption, management may need to allot engineers extra time to conduct reviews and fix bugs, as well as offer general encouragement.

“It’s unrealistic to think that you can add a step to your development process that will not have some kind of impact on work effort and schedule … In order for static analysis to ‘stick’ as a process, you need to make sure that management understands what it’s for, and is willing and able to enforce its use,” blogger The Code Curmudgeon wrote. “This of course presupposes that the tool is a good one, with low noise … If developers get messages that aren’t useful, they’re likely to ignore the results. If on the other hand static analysis saves their neck by telling them something important, then you’re on the right path.”

To drive this point home, developers should ideally be asked to revise the bugs found in their own code, Sheridan said. While it can be tempting to hand the revision process off to less experienced staff, this approach increases the risk that false positives will be misidentified – erasing much of the value static analysis provides and contributing to skepticism for the tools. Additionally, one of the benefits of static code analysis is that the practice offers a chance for developers to see their mistakes and learn to avoid them in the future.

New technological advancements from source code analysis vendor Klocwork can facilitate this type of learning by helping developers identify defects instantaneously. Klocwork’s exclusive ‘on-the-fly’ spell-check model flags issues as code is written, allowing the developer to fix defects on the spot and learn from his or her mistakes.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top