[SystemSafety] McCabe¹s cyclomatic complexity and accounting fraud

[Derek M Jones]

Steve,

> ³Software complexity is not a number, it is a vector²

A vector of what, low viability metrics?  Throw enough in and
some pattern will emerge?

> Of course one can simply refactor code to reduce Cyclomatic Complexity and
> yet the inherent complexity didn¹t go away. It just moved. But that¹s
> kinda the whole point. Knowing that, can I call it, ³local complexities²

The whole point is to commit accounting fraud?
The box has to be ticked and everybody else does it.

> like Cyclomatic Complexity and Depth of Decision Nesting can be traded
> for, can I call it, ³global complexities² like Fan Out, the developer¹s
> goal should be to strike an appropriate balance between them. Not too much
> local complexity balanced with not too much local complexity.

What is an "appropriate balance"?  Do you have a formula for this?
What does having an appropriate balance buy you?

> This is covered in a lot more detail in Appendix N of the manuscript for
> my new book, available at:
> 
> https://www.dropbox.com/sh/jjjwmr3cpt4wgfc/AACSFjYD2p3PvcFzwFlb3S9Qa?dl=0

You cite an author name for what I take to be this paper:
https://pdfs.semanticscholar.org/e3d6/6c47ee0ddb37868c51ca30840084263ee1f1.pdf

More of a semi-puff piece paper than a description of serious 
research.Anyway, you are relying on Figure 4 to back up your claims 
(reproduced
in your figure N-2).

"Figure 4 illustrates the results of using the cyclomatic complexity
metric to analyze one of the PowerBuilder systems."

What about the other 17 systems that the paper refers to?
Do they show very different behavior?

There are several ways of interpreting that plot.  It could be
a percentage of lines of code or a percentage of methods.  The
original paper is not clear.

There are lots of Not Availables in Table 1.

Are you not embarrassed, having to rely on this figure?

> 
> 
> -----Original Message-----
> From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
> on behalf of Derek M Jones <derek at knosof.co.uk>
> Organization: Knowledge Software, Ltd
> Date: Wednesday, March 28, 2018 at 7:21 AM
> To: "systemsafety at lists.techfak.uni-bielefeld.de"
> <systemsafety at lists.techfak.uni-bielefeld.de>
> Subject: Re: [SystemSafety] McCabe¹s cyclomatic complexity and accounting
> fraud
> 
> Paul,
> 
>> There is the reported McCabe Complexity value for each function in a
>> system. Yes, you can do things to reduce individual function complexity,
>> and probably should. However, you then need to take the measure a step
>> further. For every function that calls other functions, you have to sum
>> the
> 
> I agree that the way to go is to measure a collection of functions
> based on their caller/callee relationship.
> 
> This approach makes it much harder to commit accounting fraud and
> might well produce more reproducible results.
> 
>> for the entire system on this basis. It becomes clear when you have too
>> many
>> functions with high complexity factors as it pushed up the average
>> complexity
>> value disproportionately. It still should not be the only measure though.
> 
> Where do the decisions in the code (that creates this 'complexity' come
> from)?  The algorithm that is being implemented.
> 
> If the algorithm has lot of decision points, the code will contain
> lots of decision points.  The measurement process needs to target the
> algorithm first, and then compare the complexity of the algorithm with
> the complexity of its implementation.  The code only needs looking at
> if its complexity is much higher value than the algorithm.
> 

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com