[SystemSafety] Koopman replies to concerns over Toyota UA case

[Derek M Jones]

Matthew,

Koopman's slides contain the numbers I now have:
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf

> Going back to the Toyota software case itself I think we can also
> reasonably conclude that there were (at least) two basic principles that
> the design violated. I took a stab at discussing why in the link below.
>
> https://criticaluncertainties.com/2013/11/11/toyota-and-the-sphagetti-monster/

McCabe Cyclomatic Complexity metric needs to be taken outside and shot.
It is trivial to game this metric (e.g., split high value functions
up into smaller functions), the metric goes down but the complexity is
still there.

Nature (and humans) abhor a vacuum, so until something more realistic
comes along we are stuck with an easily gamed metric.

Did anybody talk to the engineer who wrote the function for which
"Throttle angle function complexity = 146"?
Perhaps he carefully weighed the options and decided that everything in
one function was the best option.
Why did the people involved in this function choose game the system
by splitting it up into smaller functions?

All code can be tested and maintained.  There are thing that can be
done to reduce the time and cost of testing and maintenance.  Claiming
that code is untestable or unmaintainable is a marketing statement, not
engineering.

> On 30 December 2017 at 5:32:38 am, Peter Bernard Ladkin (ladkin at causalis.com)
> wrote:
> 
>> On 2017-12-30 01:51 , Matthew Squair wrote:
>>
>> I read David’s piece, and came away thinking oh dear what a special
>> snowflake.
>>
>>
>> There is no doubt that Cummings's arguments are poor. The question arises
>> why someone of his
>> experience might publish them (Phil mentions a plausible reason in his
>> rebuttal).
>>
>> I summarise them and make some observations of my own at
>>
>> https://abnormaldistribution.org/index.php/2017/12/30/david-cummings-on-phil-koopmanmichael-barrs-unintended-acceleration-testimony/
>>
>>
>> PBL
>>
>> Prof. Peter Bernard Ladkin, Bielefeld, Germany
>> MoreInCommon
>> Je suis Charlie
>> Tel+msg +49 (0)521 880 7319 www.rvs-bi.de
>>
>>
>>
>>
>>
>> ------------------------------
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE
>>
> 
> 
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> 

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