[SystemSafety] Koopman replies to concerns over Toyota UA case

[Matthew Squair]

Hi Derek,

I agree, relying purely on McCabes metric as evidence would be unwise, even
for a forensic exercise.

But if you add to that McCabes metric of 146 that the throttle angle
function software code was 1400 lines long, and that there was no
associated unit test plan for the function (Barr’s report, quoted by Phil
Kooperman) then it’s a reasonable conclusion that testing of this chunk of
spaghetti would be quite difficult (and error prone) and that likewise
making modifications to it would be quite difficult (and error prone), as
RAC point out in the quoted excerpt. Not much economy of effort.

As you point out you can always maintain anything given enough resources,
so perhaps I should have said ‘costly and problematic to maintain’.
Especially in the the organizational context that Phil describes in the
latter part of the presentation.

On 30 December 2017 at 11:35:00 am, Derek M Jones (derek at knosof.co.uk)
wrote:

> 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
> _______________________________________________
> 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/20171230/3215bfa0/attachment-0001.html>