[SystemSafety] Koopman replies to concerns over Toyota UA case

[Derek M Jones]

Clayton,

>  I think this was just used as an example for laypersons.

Yes, I think this is probably the case.

But it is a bad example in that it is training laypeople to think
of code as the problem, rather than the people doing/managing the
coding.

If you were given two sets of source code metrics, one from
a thoroughly tested system and one from a basis tests only system,
do you think you could tell which was which?  I know I would
have problems telling them apart.

I was at a workshop on code review last month
http://crest.cs.ucl.ac.uk/cow/56/
and asked why researchers spent most of their time measuring
source code, rather than talking to the people who wrote it.
The answer was that computing was considered part of
engineering/science and that the social or psychological aspects
of code reviews was 'social science', which is not what people
in computing were expected to do or perhaps even wanted to do.

>> Did anybody talk to the engineer who wrote the function for which
>> "Throttle angle function complexity = 146”?
> 
> That is the big question, isn’t it?  AFAIK, there was little evidence during development of anyone asking that question, much less providing an answer.  I believe in the testimony it was stated there was little evidence of code reviews.

This is the key evidence and what we should putting in examples to
inform laypeople about the important human factors.

 From Matthews reply:
 > 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

McCabes highly correlates with lines of code.

I could chop up that 1,400 lines into 100 functions, containing an
average of 14 lines each.  The metric values would merge into the
background noise, but the intrinsic complexity would remain.

>>   Claiming
>> that code is untestable or unmaintainable is a marketing statement, not
>> engineering.
> Slides aside, I believe the engineering position was  "infeasible # of tests required…” or something like that.

Infeasible from what perspective?  Money budgeted, maximum that could
be spent and the company still make a profit, maximum the customer is
willing to pay for a car (the regulatory could have a say in the last
option)?

Chopping the 1,400 lines up into 100 functions does not make the
testability problem go away, the ticked boxes on the metrics sheet
just makes it appear to have gone away.

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