[SystemSafety] Koopman replies to concerns over Toyota UA case

[Les Chambers]

Granted we are talking forensic analysis here - but I can't help myself. A McCabe number is a lag indicator. I know Phil, detecting a big one gives the forensic analyst a warm feeling (much like peeing in your pants) "Arr huh. I've found the problem!". But from a practical point of view it's too late. Projects never have the money to rewrite the offending code. Better to look at the upstream causes of excessive complexity and to develop lead indicators for them. A few examples are:

1.       No architecture. Code bodies that grow like topsy and are hacked over the years by itinerant coders with widely varying skill levels, into an unintelligible spaghetti mess. This is easy to spot. Find the architect, ask him to brief you on his architectural approach. What architectural design pattern is he using, what framework is using ... ?

2.       Bad architectures. That do not properly partition the solution into manageable code chunks. I once asked a so-called architect to brief me on his partitioning strategy. He had no idea what I was talking about. ... That do not lay down the inviolable rules, for example thou shalt not use globals

3.       Good shelfware architectures. Beautiful system architecture specifications that become shelfware and are admired from afar but not implemented especially under deadline death march conditions. 

4.       No model based development. Code hacked from a blank page with no consideration of highly effective modelling techniques - the ones that support simplicity and cut LOC counts. The classic example is control systems that do not make extensive use of state engines.

 

My point is that the critical review is the design review not the code review. The code review is the too-late-review especially if it's done close to delivery, or in this case over a dead body.

 

Les

PS: I'm not against McCabe. It's a good tool to have on code check in. If your number is in Steve Tockey's red zone just get ready to have a good story. It keeps coders on their toes.

 

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Matthew Squair
Sent: Monday, January 1, 2018 4:47 AM
To: Derek M Jones
Cc: Bielefield Safety List
Subject: Re: [SystemSafety] Koopman replies to concerns over Toyota UA case

 

 

As I see it the problem/opportunity to ‘game’ McCabes metric is similar to how you can game risk assessements by picking a lower level in the system (say at the subsystem) at which to evaluate risk. Which as each subsystem contributes only a part of the total means that their individual risks will be less (yes I have seen folk do this). The antidote in that case is to consider the total risk rather than individual subsystem risks alone. 

 

In the case of McCabe by salami slicing the function up (part/whole style hierarchy) as Derek proposed we’re pushing the complexity up into the next higher system level where, as McCabe doesn’t have a concept of hierarchy, it somewhat conveniently ‘disappears’. Again the antidote is to recognize that the complexity hasn’t gone any where though a simple budgeting exercise. In line with other budgeting practices I’d (aspirationally) look for who owns that higher level of system design and what the practices were for proposing and accepting such transfers. 

 

Touching on complexity theory, as I see it McCabe is more a measure of local (flat) complicatedeness (which still poses difficulties) rather than ‘true’ complexity (ie hierarchy, abstraction, emergence). To make it more a measure of complexity it should have, or be augmented by other measures) to have, an ability to deal with hierarchy at least. 

 

The other dimension is to consider the system from a means-end rather than part-whole hierarchy, ‘generally’ people don’t write complicated code for the hell of it so if the ‘means’ has a high metric, chances are if we look back up at the ‘end’ required it’s going to be the driver and there may be an opportunity to refactor the requirements. 

Apologies for the scattergun of the above, on a short layover in NZ.

 

Regards, 

On 1 January 2018 at 2:32:54 am, Derek M Jones (derek at knosof.co.uk) wrote:

Steve, 




Are you saying that there should be NO constraints whatsoever on the code 
a developer writes? Are you willing to accept the following because I have 


I'm saying that people should stop demonizing an easily gamed metric. 
It increases the pressure on people at the sharp end to commit 
account fraud. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180102/a1ac4a96/attachment.html>