Static Analysis - is it ROIng or not ROIng

Today I would like to talk about pattern based code checking (aka Static Analysis aka Coding Standards) - a very powerful technique which allows you to improve quality of your code in no time.

The idea is pretty simple - programming is an activity of coding based on the grammar, which is somewhat regular, and that means that programs will have similar patterns in their code. This is where bad and best practices come from. Now if we have means to analyze the program structure (given by existence of grammar) and we have patterns of different quality - we can promote good over bad patterns and that improves the overall quality of our software.

How would you do that - the easiest technique is to find and eliminate bad patterns in existing code. There is a wealth of products which not only can analyze the structure of your code but have tens or hundreds of such best practices built in. They integrate with our development IDEs, allow for extensions (defining your own rules), manage results of analysis, sometimes have auto-fix feature (apply standard refactoring to replace bad practice with its' better equivalent).

Now, there is a lot of discussion on whether it is necessary to use static analysis in your development lifecycle. The arguments are that this practice is not about chasing errors which would necessarily trigger off at some point of a user experience and kill our application in front of her eyes, this is more about preventing errors by writing in 'better style'. If we look at it from the return of investment side, we have to consider three costs - cost of the product, cost of introduction of the product, cost of using it.

As for the cost of the product - it's usually in whereabouts of several thousands dollars. Just think about it as a vehicle to make junior developer into senior one by putting it at its belt. Do the math how quickly it pays off.

As for the cost of introduction - back in the eighties there may have been some learning curve involved in this (as everything was command line based then), but now it just plugs in into your development environment, you work with results by clicking, it jumps with you to specific places in the code which require modification, explains what to do and why to do it. From time to time I train people on various kinds of testing. Static analysis takes about two-three hours (including rules configuration, suppressions mechanisms etc.). Again I'm leaving the math for you.

As for the cost of using it - processing time is pretty much about the same (up to three times longer) as normal compilation and it suits kind of similar purpose (checks whether code is sound and you can progress based on it with your development), so if you allow your team to compile code as they go, you should be ok with them running static analysis. Than there is working with results - first of all usually there is one click to assess whether violation should be fixed or not - it takes literally seconds. No false positives (of course if software doing analysis is not buggy itself).

And now for the ROI - depending on sources and lifecycle phase we have the cost of single defect removal varying from 1,000$ to 20,000$ and more.

That leaves it as a no-brainer. After three, four defects are removed, we have our price of the product paid off and we are left with developer directly connected to the oracle of coding wisdom.