Why Static Analysis is Not Another Episode of CSI

Static analysis of the past has been like an episode of CSI. Some guys in specially marked uniforms enter the scene and photograph memory leaks, establish attack vectors and scrape some dangling pointers off the ceiling. Then they go back to the lab and try to figure out what happened. It’s a post-mortem investigation of something that went horribly wrong.

This could be the tale of a real mission critical bug in the wild or just something that slipped through until final system testing. By any means it probably indicates that someone or something got burned. While many of our customers use our Goanna static analysis tools to establish final code quality or to do some forensic analysis, there are also many opportunities for prevention available that are often overlooked.

We carefully designed Goanna Central and Goanna Studio for two different purposes: Goanna Central can be quickly integrated into the build process and invoked either nightly or at the finish of a project. In any case it gives you an accurate snapshot of your code confidence. This is a must. But ideally, you want your code as clean as possible before it moves upstream in the SDLC. Just imagine how much could be saved by only committing “non-lethal” code to your project; If developers are empowered and can fix code right when they produce it. No more blame games.

We at Red Lizard Software really believe that the maximum value of static analysis tools comes from their usage by developers on an everyday and even every minute base. We try to make deep static analysis ridiculously easy. Checks that still required dedicated severs a few years ago will run on simple laptops with Goanna Studio today.

The advantages are clear: Developers can fix bugs before they are committed, development-testing periods are drastically reduced and products can hit the market sooner with higher quality. Maybe one day we will not need the CSI guys at all.

1 Comment
  • Andy

    November 11, 2010 at 5:58 am

    Many savvy organizations now have a criteria that high or critical bugs (static analysis or otherwise) must be fixed before the next continuous integration cycle/nightly build/etc. By giving developers the chance to find, fix and verify static analysis bugs before check-in, they have the ability to root out problems before they affect the team.

Post a Comment