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

Thu Jul 4 07:22:22 CEST 2013

>From economics theory that studies decision making under uncertainty due to
imperfect information. Information asymmetry models assume one party to a
contract or agreement has more information than the other and looks at how
this can result in adverse selection or moral hazard market failures.
Classical market theories assumed perfect information, of course that's
usually not the in the case.

George Akerlof's essay 'The Market for Lemons' seems very applicable to the
scenario that's been discussed. He pointed out that in the context of a
used car market because quality is "unknown" by a customer people assume
that all cars are lemons, this sets the market price low and drives good
cars out of the market. A classic example of asymmetric information effects.

There's a consideration here also of the appropriate role of design
authorities (or other technical governance mechanisms) in addressing and
reducing such information asymmetries within the design space. I touched on
it briefly in this post
http://criticaluncertainties.com/2011/08/01/authority-versus-agency-in-design/#more-4615
.

On Thu, Jul 4, 2013 at 10:02 AM, Les Chambers <les at chambers.com.au> wrote:

>  Matt****
>
> I'm intrigued. Could you expand on that sentence please.****
>
> Les****
>
> ** **
>
> *From:* Matt Squair [mailto:mattsquair at gmail.com]
> *Sent:* Wednesday, July 3, 2013 7:56 PM
> *To:* Les Chambers; Bielefield Safety List
>
> *Subject:* Re: [SystemSafety] The "Real world" [was: Qualifying SW as
> "proven in use"]****
>
>  ** **
>
> A special case of information asymmetry economics perhaps? ****
>
> ** **
>
> --
> Matt Squair****
>
> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>****
>
> ** **
>
> On Wednesday, 3 July 2013 at 10:49 AM, Les Chambers wrote:****
>
>   In the recent past someone classified the act of****
>
>
> knowingly-taking-short-cuts-in-software-development-that-have-negative-effec
> ****
>
> ts-downstream as "taking on technical debt". There is an excellent set of*
> ***
>
> articles on the subject in IEEE software November/December 2012 issue. See:
> ****
>
>
> http://saturnnetwork.wordpress.com/2012/02/29/ieee-software-special-issue-on
> ****
>
> -technical-debt/****
>
> It's a compelling metaphor. I was recently working with some air force****
>
> officers who were very excited about the concept as it neatly described the
> ****
>
> situation that they were in – taking on a vendor's technical debt. An****
>
> associated metaphor is "paying down technical debt" - which applies to****
>
> refactoring crap code. These metaphors are very useful in explaining to***
> *
>
> non-technical managers what a good idea it is to do it right the first
> time.****
>
> ** **
>
> -----Original Message-----****
>
> From: systemsafety-bounces at techfak.uni-bielefeld.de****
>
> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] On Behalf Of Steve*
> ***
>
> Tockey****
>
> Sent: Tuesday, July 2, 2013 3:00 AM****
>
> To: RICQUE Bertrand (SAGEM DEFENSE SECURITE);****
>
> systemsafety at techfak.uni-bielefeld.de****
>
> Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as "proven
> ****
>
> in use"]****
>
> ** **
>
> ** **
>
> Bertrand,****
>
> The silliest thing in all of this is that the stakeholders are clearly****
>
> clueless about the true source of cost in their software projects. We've**
> **
>
> actually measured the degree of rework (fixing things that were done****
>
> incorrectly earlier, simply, waste) in software organizations to be over**
> **
>
> 50%. I've got a technical paper on the topic, if anyone wants. I don't****
>
> believe I can include attachments on this list, so if anyone wants just***
> *
>
> email me direct and I'll sent it back as a PDF attachment.****
>
> ** **
>
> The root issue here is that corporate accounting systems lie. They are****
>
> *cost* accounting systems, not *value* accounting systems. They are great*
> ***
>
> for measuring how much money was spent, but they fail miserably at****
>
> measuring how much money was saved.****
>
> ** **
>
> The corporate accounting systems will surely measure the cost of doing****
>
> everything we're talking about on the list recently. But tell me where the
> ****
>
> accounting system measures how much was saved because we did it a better**
> **
>
> way? It doesn't. It can't. So the key problem underneath all of this is an
> ****
>
> inability for the stakeholders to really see and appreciate the economic**
> **
>
> impacts of what's being discussed here. I'm convinced that if they had a**
> **
>
> clue of the value of doing things better, they'd demand that it be done***
> *
>
> that way.****
>
> ** **
>
> ** **
>
> -- steve****
>
> ** **
>
> ** **
>
> ** **
>
> -----Original Message-----****
>
> From: "RICQUE Bertrand (SAGEM DEFENSE SECURITE)"****
>
> <bertrand.ricque at sagem.com>****
>
> Date: Monday, July 1, 2013 2:05 AM****
>
> To: "systemsafety at techfak.uni-bielefeld.de"****
>
> <systemsafety at techfak.uni-bielefeld.de>****
>
> Subject: Re: [SystemSafety] The "Real world" [was: Qualifying SW as****
>
> "proven in use"]****
>
> ** **
>
> I agree and I am afraid that we are just requested to stop bothering****
>
> stakeholders by raising issues understood as costs.****
>
> ** **
>
> Bertrand RICQUE****
>
> Program Manager, Optronics and Defense Division****
>
> T +33 (0)1 58 11 96 82****
>
> M +33 (0)6 87 47 84 64****
>
> 23 avenue Carnot ****
>
> 91300 MASSY - FRANCE****
>
> http://www.sagem-ds.com****
>
> ** **
>
> ** **
>
> ** **
>
> -----Original Message-----****
>
> From: systemsafety-bounces at techfak.uni-bielefeld.de****
>
> [mailto:systemsafety-bounces at techfak.uni-bielefeld.de] On Behalf Of Martyn
> ****
>
> Thomas****
>
> Sent: Monday, July 01, 2013 10:56 AM****
>
> Cc: systemsafety at techfak.uni-bielefeld.de****
>
> Subject: [SystemSafety] The "Real world" [was: Qualifying SW as "proven in
> ****
>
> use"]****
>
> ** **
>
> 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****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> The System Safety Mailing List****
>
> systemsafety at TechFak.Uni-Bielefeld.DE****
>
> #****
>
> " Ce courriel et les documents qui lui sont joints peuvent contenir des***
> *
>
> informations confidentielles ou ayant un caractère privé. S'ils ne vous***
> *
>
> sont pas destinés, nous vous signalons qu'il est strictement interdit de**
> **
>
> les divulguer, de les reproduire ou d'en utiliser de quelque manière que**
> **
>
> ce soit le contenu. Si ce message vous a été transmis par erreur, merci***
> *
>
> d'en informer l'expéditeur et de supprimer immédiatement de votre système*
> ***
>
> informatique ce courriel ainsi que tous les documents qui y sont attachés."
> ****
>
> **********
>
> " This e-mail and any attached documents may contain confidential or****
>
> proprietary information. If you are not the intended recipient, you are***
> *
>
> notified that any dissemination, copying of this e-mail and any****
>
> attachments thereto or use of their contents by any means whatsoever is***
> *
>
> strictly prohibited. If you have received this e-mail in error, please****
>
> advise the sender immediately and delete this e-mail and all attached****
>
> documents from your computer system."****
>
> #****
>
> ** **
>
> _______________________________________________****
>
> The System Safety Mailing List****
>
> systemsafety at TechFak.Uni-Bielefeld.DE****
>
> ** **
>
> _______________________________________________****
>
> The System Safety Mailing List****
>
> systemsafety at TechFak.Uni-Bielefeld.DE****
>
> ** **
>
> _______________________________________________****
>
> The System Safety Mailing List****
>
> systemsafety at TechFak.Uni-Bielefeld.DE****
>
>  ** **
>

-- 
*Matthew Squair*
*
*
Mob: +61 488770655
Email: MattSquair at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130704/2ce6f4ab/attachment-0001.html>