Mark Grice is a pretty unflappable guy, but when you ask him a question about barriers to successful adoption of Source Code Analysis (SCA) technology, he starts to splutter.
- Make sure your SCA tool evaluation process is long and costly.
“I’ve seen companies spend three years in the analysis phase, involving a number of key staff,” Grice says. His advice? “Buy them all and just start using them. At least you’ll have spent three years producing better code instead of just testing and evaluating.” Or, just buy one and start using it. If it doesn’t do everything you want it to, buy another one.
- Cling to your tool-selection criteria to the point of impotence.
“I’ve seen companies not buy a tool because they couldn’t check off one requirement out of 100. It didn’t matter that the other 99 criteria were met,“ Grice says. Often, these checklists eliminate every tool. These companies opt to do nothing rather than something about their code quality.
- Insist that one tool must do everything.
No one tool will do everything. Buy a couple of them. “If I’m working on a construction project and I need to drive some nails and cut some wood, I’m going to go and buy a hammer and a saw.” What? There’s no such thing as a sammer (or a haw) for both those tasks?
- Focus solely on the number of false positives the tools throw.
“A zero false-positive rate is ridiculous,” Grice says. A very low false positive rate is often tied to a higher false negative rate. It’s easier to manage false positives than false negatives, particularly since the latter rear their ugly mugs after your product is shipped, he says. If a tool is tunable and customizable, you can just filter or turn off the defect types that don’t interest you.
- Denial: You don’t have to fix problems if you don’t find them.
“Gack!” Grice has to do deep breathing to get through this one. “If you don’t want to find anything, then don’t test! I mean, jeez!”
- Have a persecution complex: Management will use the information against us.
Developers sometimes worry that they’ll be ranked by number of defects per lines of code. But if you’re finding and fixing defects before you check in, your numbers will actually improve. “I’ve seen one team resist the SCA tool because they were at the top of their game. Then that team saw their ranking fall because teams using the SCA tool made consistent quality gains with every build and then caught up and then surpassed them,” Grice says.
- Make non-development staff responsible for rolling out the SCA tools.
“I know we’re in for it when the prime asks, ‘What’s a build?’ or ‘What’s make?’”
To successfully roll out, Grice says, you need a code expert–someone who really understands your build process, the development environments and how to evaluate the findings.