7 habits for highly ineffective source code analysis

on Jun 29, 10 • by Patti Murphy • with 3 Comments

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. “There are things I see over and over that make me want to bang my head against a wall,” says the Klocwork Director and Manager of ...

Home » Software Quality » 7 habits for highly ineffective source code analysis

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.

“There are things I see over and over that make me want to bang my head against a wall,” says the Klocwork Director and Manager of our International Reseller/Partner Network.  For the past nine years, Grice has helped companies from around the world to successfully implement SCA.
There are many companies that deploy SCA tools and reap their ROI, but there are others that can’t get to first base.  Below are barriers Grice has consistently encountered from a persistent minority.
Here are 7 sure-fire ways to ensure that your organization will fail at SCA:
  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. 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!”
  6. 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.
  7. 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.
And there you have it—your SCA-failure habits. We’ll end here because Grice has to go and get his  blood pressure checked.

Related Posts

3 Responses to 7 habits for highly ineffective source code analysis

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top