Who here knows what McCabe Cyclomatic Complexity is? Anyone?
<silence>
It’s a term from computer science that defines the complexity of a computer program. I have a degree in computer science (kinda*), and I’ve never heard of this term – so don’t feel bad if you are not familiar with it.
At Award Consulting we have a team meeting every morning, and last week Stephen Denny decided to educate us about McCabe Cyclomatic Complexity – I’m still not exactly sure why. But yes, it was fascinating, and yes, our team meetings sometimes take weird tangents.
What is Cyclomatic Complexity?
There’s a complicated definition involving graphs and nodes and edges, but the simple version is this:
It’s a number representing the complexity of a computer program, specifically the number of paths that can be taken through the code.
So if you have a simple process that says “If it’s the weekend, take the day off, else go to work”, then that would have a cyclomatic complexity of 2, because there are two choices (take the day off, or go to work). You can see that the more choices there are (i.e. the more paths through the code), the more complex the logic must be.
Why do computer programmers care?
Thomas McCabe proposed this idea in 1976 because he thought it was bad for programs to be too complex. In fact, he didn’t just come up with the number – the measurement of complexity – he also recommended that no computer program should have a complexity greater than 10.
His recommendation was that if you ever had a piece of code with more than 10 possible paths through it, you should split that code into multiple modules – where each module was nice and simple to understand.
And it turns out that this is a good idea. Researchers have found that the higher the cyclomatic complexity of a computer program, the more bugs there are in it. So keeping things simple is the best way to find success.
Why should telecoms engineers care?
Most people reading this don’t write code for a living (nor do I, any more), but the idea that you need to keep systems simple in order to limit defects is valuable for any kind of system or network.
- Switch Translations: Anyone who has attended a translations training class at Metaswitch will know that it’s best practice to keep each table very simple. Each table should only do one job. Yes it’s possible to look at 3 different fields in a Number Validation table, but everyone who tries to look at your logic later will be confused, and it’s likely to lead to mistakes.
- Trunk Groups: How many different paths are there through your voice network? How many different trunk groups do you have? Are all subscribers treated the same, or do you have different classes of subscribers that are routed with different logic? There are always good reasons for adding complexity, but unless you’re very careful, you’ll end up with a huge mess that no-one understands and is impossible to maintain.
- IP network: The same question applies to your IP network. How many routers and links are there? Is each subnet simple and does it serve a single purpose? If someone looked at your IP routing tables would they quickly understand what you’re doing and why?
I think my team is particularly sensitive to these kinds of issues, because we see it a lot. Technician A built a network, and maintained it for 25 years. He/she understood it just fine, but then Technician A retired, and no-one else has a clue how anything works, and whenever you try to make a small change calls start failing.
If you’re already in that situation, let me know and we’ll help you out. It may not be easy (even for us), but our team has many decades of experience, so if anyone can untangle the knot, it’ll be us.
If you haven’t reached breaking point yet, then hear this plea: aim for simplicity! Any time you make a change to some kind of routing logic, look for a way to simplify things – or at least write a clear description of what you’re doing and why! Future generations of voice technicians will thank you.
*Not that anyone cares, but my degree is in Mathematics and Computation, where the Computation half was basically academic/theoretical computer science.
