[SystemSafety] The "Real world" [was: Qualifying SW as "proven in use"]

Martyn Thomas martyn at thomas-associates.co.uk
Mon Jul 1 10:55:50 CEST 2013


On 01/07/2013 01:01, Les Chambers wrote:
> I encourage the
> brains trust on this list to engage with the aggressive ugliness that is the
> real world and consider how we might deal with it.

I recall a lecture given by Dijkstra in 1973. A member of the audience
asked " do your methods work on real world problems?" Dijkstra paused,
and then said quietly "real world problems. Ah yes, those that remain
when you have failed to apply all the known solutions".

Over the years, I have heard many excuses for failures to use
professional engineering methods.

"if we train the programmers, they'll leave for a better paid job".
"we can't hire programmers who are willing to use that programming language"
"universities don't teach (maths, project management, quality control,
planning, team working ... ...)"
"the customer insists that we use this (buggy) middleware for compatibility"
"modern software isn't written - it's assembled from lots of (buggy) COTS"
"if we try to include that in the standard, industry will revolt."
"if we were to ask for that evidence, industry would charge us a fortune"

... and many many more.

Most software developers appear to have lost sight of the problem. Every
week, I hear someone use the verb "test" when what they mean is "gain
assurance that  ... is fit for purpose"; this reveals a dangerous,
implicit assumption that "test-and-fix" is the only practical way to
develop software. Most software is still written in languages without
good data structures and strong type-checking. Most software
requirements (and even interface specifications) are written in English
(or another natural language) - perhaps with some diagrams that lack any
rigorous semantics. Most projects have grossly inadequate change
control. I rarely see a risk register that is worth anything (except as
a demonstration that the project manager isn't managing the project).

Is there another trade that (a) builds complex, novel and critical
systems using poorly-qualified staff, (b) almost exclusively uses tools
that have major known defects, (c) builds systems from components of
unknown provenance that cannot be shown to be fit for purpose and (d)
nevertheless claims to be professional engineers?

Surely it is self-evident that the current state of our profession is
unsustainable. Let's stop making excuses and look for ways to accelerate
the changes that we know are needed.

(Which may be what Les was saying in the extract quoted above).

Martyn








More information about the systemsafety mailing list