Thursday, February 12, 2009

Cyclomatic Complexity

Much of my day is spent convincing engineers that there are simpler ways of implementing their designs. Much of the rest is convincing executives and managers that what they want isn't simple at all.

Invariably some little hot-head tries to argue with me that implementing a general case is more complicated than a special optimized case. If the punk in question has cracked a book they'll likely bring up some metric like Cyclomatic Complexity.

Thomas McCabe socialized this metric in the 70's as a mechanism for predicting where code would have future maintain problems. It's often thrown into the blender when people are trying to construct qualitative measures for code quality. Here's the formal equation:

CC = E - N + P

E = number of edges N = number of nodes P = number of connections or exits

It can be hard to see how equations like this apply to code so let me say it a different way: Cyclomatic Complexity represents the number of code paths through a section code.

How do you count the code paths? Start with one for the entry into the code, and add one more for every decision point. Decision points are the control of flow statements like If…Then…Else or Switch. The CC for the following snippet is three (3).

public int adjustRange( int rangePrimary ) {
bool adjustedValue = 42;
if ( rangePrimary == 6 ) {
adjustedValue = 42;
} else {
adjustedValue = 9;
return adjustedValue;

This example was really simple but is illustrative of how the CC may be calculated.

So how complex is complex? As with most metrics, the interpretation is very subjective. Since the higher the number, the more complex the code, it stands to reason that code with higher numbers would be more prone to issues. Perhaps bugs because of the logic convolutions, or issues with maintenance because of the number of things impacted by even simple changes. In a sweeping generalization I can say that for my reviews, code with values higher than 20 would be suspect, and higher than 30 would likely not pass.

The important thing is to realize it isn't a measure of quality, just an indicator where better organization or testing might be advisable. Personally, I tend to gauge an engineers competence inversely to the CCs of the code they routinely produce. In my experience, engineers who write better code routinely produce code with low CCs and vice versa.

Friday, February 06, 2009

A Goofball CEO and a Silly Journalist

If you run a major international company, you shouldn't be dropping cuss words in public. IMHO.

In a recent article, the SAP co-CEO Leo Apotheker was quoted making some of the dumbest CEO comments I've ever heard. I wonder what how big his *ahem* bonus must be for him to so blatantly disregard common sense.

The follow-on article was equally hilarious. It shows how much pressure the Old Timers are under to stay relevant. Add this to the recent absurdity of the Satyam Scandal and it becomes clear some house cleaning is in order.

I found the most insightful comment in the follow-on to be:
The core of most cost/time overruns stems from CIOs committing to ERP, but middle managers insisting after implementation is already well underway that the software be changed to accommodate legacy business processes rather than the other way around. -- Eric Krangel

Amen, brother.

But wait, it doesn't stop there. You have to read the comments too. Here's my favorite:
Accenture made me rich when we IPO'd it in 2001.
I'm willing to forgive all else.

-- Maurice (commented on the Alley Insider article)

That pretty much sums up how the Bozo Effect is getting worse. I think it's time to go back into retirement. Again.

Or maybe a start-up? Hmmm...