[SystemSafety] a discursion stimulated by recent discussions of alleged safety-critical software faults in automobile software

Matthew Squair mattsquair at gmail.com
Mon Nov 11 22:26:33 CET 2013


I prefer the analogy of trying to push an elephant with a piece of (cooked)
spaghetti.

The thing is, and taking the plaintiffs allegation as true, Company X had
to really 'work' at making their software as bad as it was. There were, on
paper at least, a series of safety mechanisms each of which needed to be
negated in some fashion. How a company or departmental or team culture
arose that could foster such normalised deviance is the question for me.

Rules, processes and practices are great, but they need a culture of
compliance. That in turn needs a corporate understanding of the difference
between governance and management. Most management in my experience
struggle with that difference, and quite a few boards as well.

Matthew Squair

MIEAust, CPEng
Mob: +61 488770656
Email; Mattsquair at gmail.com
Web: http://criticaluncertainties.com

On 12 Nov 2013, at 6:49 am, Steve Tockey <Steve.Tockey at construx.com> wrote:


Martyn wrote:
"But a man can dream and, if such a set of circumstances were ever to
arise, why would I care whether the bad software did actually cause the
accident?"

I, for one, would care if the damage of said accident happened to *me*...

My concern is that it's the sorry state of software development practices
that leads to these safety vulnerabilities (and the vast majority of those
other irritating defects) in the first place. As I've said before, the
practices needed to develop safety/mission critical software can--for the
most part--deliver high quality software at lower cost and shorter
schedule than 'standard practice'. These problems are a direct result of
the sloppy, immature, UNPROFESSIONAL approach that most dev groups take.
Doing the job right is not only easier, it's better, faster, and cheaper.
But, as we say in the US, 'it's like trying to push a rope uphill'.
Day-to-day amateur practitioners aren't going to care about doing a good
job until some obvious, high-profile disaster can be pinned directly on
the crappy level of standard practice.


Cheers,

-- steve


-----Original Message-----
From: Martyn Thomas <martyn at thomas-associates.co.uk>
Reply-To: "martyn at thomas-associates.co.uk" <martyn at thomas-associates.co.uk>
Date: Monday, November 11, 2013 6:39 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: [SystemSafety] a discursion stimulated by recent discussions of
alleged safety-critical software faults in automobile software

(I'm writing this in England. We don't have a constitution that
guarantees freedom-of-expression. Indeed, we have become a favourite
destination for libel tourists. )

Let's suppose that in a purely fictional sequence of events, a
manufacturer that develops and sells safety-related consumer products
installs some very badly written software in one of their products:
software that could lead to injury or death. Let's further suppose that
an accident happens that, when investigated, turns out to be of the sort
that the bad software could have caused.

Let's speculate that n this fictional case, the manufacturer suffers
serious penalties and as a result vows to write much better software in
future, changes their development methods, significantly reduces the
likelihood of safety-related errors in their future products, and (by
acting as a warning to others of the consequences) influences other
companies to make similar improvements.

That would be a lot of good things that resulted from the discovery of
the badly-written software and most or all of them might not have
happened if the bad software had been discovered without an accident and
a finding of liability.

Of course, this is fiction and the good outcomes described above are
hypothetical.

But a man can dream and, if such a set of circumstances were ever to
arise, why would I care whether the bad software did actually cause the
accident?

Martyn


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

_______________________________________________
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/20131112/3f0d282c/attachment-0001.html>


More information about the systemsafety mailing list