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

[Matt Squair]

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
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20130703/974da620/attachment-0001.html>