How to use static analysis and code metrics to win business and influence others

One bit of low hanging fruit for static analysis is when its use as a tool to communicate code quality to others. Too often, when we talk about code quality we're unable to get past the language of aesthetics, and we end up losing credibility. The key is to talk about measurable facts, not subjective opinion.

Last year, our group inherited a large C++ code base that no one wanted to work with. A senior architect of a large global services group thought the code was dreadful, and although he was correct he couldn't express it any better than complaining about the variable names.

They ended up proposing a BDUF solution, where the users wouldn't see any improvement for nine months, at which point, in theory, the entire system would be replaced.

I took a look at the code, it was scary. I ran some Coderush metrics on it, and applied Lattix DSM to it. Some facts emerged

• There were numerous methods over 5000 lines long, and a few over 20,000 lines long
• Cyclomatic complexity averaged in the fifties
• Nearly the entire code base was strongly connected. There were no independent layers.

These were facts that any technical manager could understand - maintenance of this code base would be expensive. But once I knew just how bad the code was, it was a lot less intimidating, and I realized something critical; the code could be maintained, it could be understood, and we could make incremental improvements to it while building a replacement system.

We proposed an agile solution, with the first release available in three months, but without any promises on the timeline for the end-state.

Four months later, phase two is underway, and there's lots of excitement about phase three. The large global services group? They're no longer around.

Next I'll talk about some specific tools and technologies around code reflection and static analysis