[SystemSafety] McCabe¹s cyclomatic complexity and accounting fraud

[Les Chambers]

Hey Steve
I read your Appendix N: Software Structural Complexity Metrics (3
times).Thanks for drilling down on this subject. The industry needs it. 

Reducing structural complexity has been a huge issue for me over the past
four years. Developing a complex cloud app it becomes a daily consideration.
For me, the motivating factor for low complexity is understandability, both
in development and in maintenance.

All developers have this experience: Your code gets so complex you lose
track of the logic.  It literally gets away from you. It's six o'clock at
night and you've got a headache. You wake up in the morning can't understand
what you wrote yesterday, so you throw it away and start again (that's if
you're a mature developer, we kill our children without remorse - the less
experienced punters go into nurture mode and soldier on, making it worse). 
After all, good software has much in common with good literature. The mark
of a great author is not in what is published but what the author is
prepared to throw away. Ernest Hemingway used to invite people over for the
weekend to help him purge extraneous words. A candidate metric: SLOC kill
ratio?

So if it was up to me, this appendix would stress, in the first paragraph,
"high local structural complexity makes code inscrutable and because of this
defects get injected". Write code you will understand in the morning and two
years from now. Even more important, write code somebody else can understand
two years from now. 
It's worth pointing out that no experienced programmer believes
documentation - my scars are  deep. We find truth only in what is executing.
We read code. If we cannot understand code we make mistakes - in development
and maintenance. Ergo give us a break and reduce your structural complexity.


I have a binary complexity metric. Turn on this music stream:
https://www.sbs.com.au/radio/chill
If you've got to turn it off to fully concentrate, the code you're reading
is too complex. Throw it away. Kill!
RE: fan out - the conclusions of your research citations are not intuitively
obvious to me. I am a great fan of fan out. I have a simple rule of thumb:
make all individually testable code units as stupid (read simple) as
possible. This can result in high fan out - but I don't care. Reading a five
line function is so relaxing, you can tap your foot to the music.

I try to make my methods look like a coder's maintenance manual - heavily
commented with complexity hidden in function calls and calls to other
methods. Any reader should be able to scan a method listing and get the gist
of what its doing in one pass. Isn't this just good writing practice, even
in English? Tell them what you're going to tell them, tell them, tell them
what you told them (and in the code review ask them, "what did I say"). In
this way high fan out improves cognition. I don't understand how it is
increasing defect density -  according to the researchers. Is there an
explanation for this?

Your appendix deals with static complexity only. Do you deal with
dynamic/temporal complexity elsewhere? This is of vital interest to me and
I'm sure many other developers.

Cloud apps are heavily event driven and involve asynchronous remote
procedure calls (client/server) that put complexity through the roof.
Complexity in the time domain is a killer (kernel hackers have suffered
through this for decades). There can be massive structural complexity but
also temporal complexity where various operations can be performed on
various events and event arrival can be unpredictable. 

To make things worse the behaviour of an app can be determined by front-end
code (JavaScript), individual browser rendering foibles, HTML and
accompanying cascading style Sheets (CSS), back end code (PHP) and system
product behaviour; e.g. MySQL, PHP interpreter configuration. Someone should
write a book on that subject alone.

This has safety ramifications because this technology is currently being
used to fire hellfire missiles at Middle Eastern people from bunkers outside
Las Vegas.

RE: fan in - I think it's worth drilling down on the impact of fan in on
orthogonality. 
Automobile Example: the same C function is used in the radio volume control
and the accelerator pedal signal conditioning. Then some eager beaver
optimises the function for smoother ramping of sound volume ignoring its
impact on vehicle acceleration. OOPS!

>From a programmer's point of view the motivation for high fan in is maximum
code reuse. The less code you have the less maintenance you need to do. But
lately I've been thinking that orthogonality is probably more important, so
I've been using more duplication to reduce the potential for nasty
side-effects - I sleep more soundly now.

Hope these thoughts help.
Cheers 
Les

PS: !!! completeness defect, Appendix N, line 413 .  We are engineers Steve.
We don't do ellipsis . Kill your child Steve. Kill!


-----Original Message-----
From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Steve Tockey
Sent: Thursday, March 29, 2018 6:08 AM
To: Derek M Jones; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] McCabe¹s cyclomatic complexity and accounting
fraud


All,
As I have said before,

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


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²
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.

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




‹ steve




-----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
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE