Measuring Complexity of Systems

I was reading a discussion about metrics on System Complexity and let me tell you I feel some times these
discussion are like the story where blind men went to see the elephant.(Read story here)
I am one among those blind men and this is my version of the elephant…

Question: Why do you want to measure complexity?

This is very important, because if you are a Project Manager and you are working with your work break down
structure (WBS) and you want to tag your work packet as small, medium, large, etc. depending on complexity,then you define complexity in terms of lines of code, number of activities,etc.
If you are an algorithm designer and you want to measure complexity, then you are talking about
“O” (big-oh) notations and order of “n” for your program.

So what is software architect’s view of complexity?

We divide complexity into
1) Design Complexity
2) Code Complexity

All the good practices like loose coupling and high cohesion, low dependency are factored into optimal design
complexity. Systems that are loosly coupled are highly maintainable where high cohesion improves efficieny.

Code Complexity is a software metric that can be explained using McCabe’s Cyclomatic complexity. Since any program flow can be represented as a decision tree, cyclomatic complexity is a number that represents the number of linearly independent paths in a program.

M = E – N + 2P

M = cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components.

Now, I am very much interested in Cyclomatic complexity, because I think since this measures coverage (both code and branch), this becomes very interesting factor when we talk about testability. With more testable frameworks like Microsoft MVC, we are getting more closer to Test Driven Development
(TDD). In this context, if your code complexity is low, it means that your unit is small enough to be tested
well. So idea will be to design your classes in such a way that you do more with less. Assign responsibilites
well so that smallest unit is self sufficient and can be tested. If you apply real “seperation of concerns” and design it is possible to get your interfaces designed in such a way that you can have small units that are testable. It is interesting that, this way we get hign cohesion and very loose coupling too 🙂

Thats my version of elephant 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s