How do you measure your software? There are simple metrics that help with quality, such as keeping track of the number of bugs or security vulnerabilities in your system. Trending these metrics is a no-brainer. When trending is in place, action can be taken because everyone knows 6 security vulnerabilities is worse than 5. But what about other types of software metrics (and there are many)? Have you ever heard of a maintainability metric? Halstead program volume? McCabe cyclomatic complexity? Coupling/Cohesion? The question becomes what do you do with these metrics and are they valuable?
Choosing a metric will really depend on what you’re after. A good reason for measuring your code is to get predictable quality. If you don’t have a metric in mind, the easiest place to start is with McCabe’s cyclomatic complexity metric. I’ve seen many software organizations implement this as a good measure to help predict system “complexity”. In other words, to help them understand where they may need to refactor or redesign their code. McCabe cyclomatic complexity uses a measure of the linearly independent paths in the source code and is measured on functions or methods.
McCabe’s Cyclomatic complexity uses values to define what is complex. Something greater than 20 is considered very complex. You should think about re-writing that function because it is getting out of control. Since the inception of McCabe’s Cyclomatic complexity metric, several other variations have appeared, including Extended Cyclomatic Complexity and Plain Cyclomatic Complexity. Back to the question, with so many metrics, which ones do you use and are they valuable?
No one can answer that question. In fact, software metrics is quite ambiguous. It is hard to find anyone who says,’Thou shall use metric “x” because it will help you improve quality by “y” amount.’ The value “x” and “y” just don’t exist (although many have tried to put some data together). Even more ambiguous are the values that may be defined with these metrics. Don’t get caught up with these values; they are really arbitrary. I’ve run into organizations where the majority of their code was deemed “very complex”. Does this mean they should redesign their entire code base? Certainly not. These numbers will vary depending on what you’re building. So be careful if you use the “recommended” values for any metric.
Instead of focusing on the value of your next metric, what you really should be doing is trending that metric. Find out if that value went up or down. Up bad; down good. Taking it one step further (if you really have a “thing” for the values), you could start by finding the standard deviation of your metrics. In other words, find the average value of any metric, say complexity, plus the standard deviation. Now, you can keep track of that value knowing that if you go outside your bounds of deviation, then you may want to look.
Software metrics certainly have their place and can help give some predictability on your system. In another post, I’ll talk about how you can take some low level metrics for the developers and give them insight into the software system.