[SystemSafety] Safety Culture redux

[Les Chambers]

Hiam
Yours was a great example of wrapping an idea around an emotional charge. The subtext is the blind faith placed in our software in the dark. Please accept my following programmers lament .

Imagine a pilot flying a Helicopter at night in ZERO visibility and is fully depending on instrument flight displays.
I cannot show a mistaken 1000 meters altitude instead of 10 meters (TWO additional ZEROS), because he flies at 10 meters height
among Electricity Poles, and is not aware of this dangerous situation.

A broken wing rocks on the sand
Beside a far off sea
In pitch black faith was placed in men
Christ, one of them was me

Les



> On 27 Feb 2018, at 10:48 pm, Haim Kuper <h3k at 012.net.il> wrote:
> 
> I fully agree with Tom: Thank you Les.
>  
> With regards to Les quote: "Aesthetic emotion is an emotional response to a situation when thought and feeling come together to create meaning" :
>  
> Among my examples during teaching Software Safety / DO-178, I use to describe the following:
> Imagine a pilot approach landing a 400 passengers aircraft  in poor visibility.
> He reduce the speed and approach to a point that he cannot take-off and repeat this attempt again in case of emergency.
> During these Fatal moments  we must provide the pilot a perfect 100% clear & correct aircraft altitude.
> We do place a lot of hardware and software/algorithms  to provide an intelligent "free of bugs" solution, such as independent redundancy
> sensors, Prevent-Screen-freeze, Diversity Design, and monitoring mechanisms, etc.
> In order to dramatize this example, I add the following:
> Imagine a pilot flying a Helicopter at night in ZERO visibility and is fully depending on instrument flight displays.
> I cannot show a mistaken 1000 meters altitude instead of 10 meters (TWO additional ZEROS), because he flies at 10 meters height
> among Electricity Poles, and is not aware of this dangerous situation.
>  
>  
> Regards,
> Haim Kuper
>  
> From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Tom Ferrell
> Sent: Tuesday, February 27, 2018 3:14 AM
> To: Les Chambers; systemsafety at lists.techfak.uni-bielefeld.de
> Subject: Re: [SystemSafety] Safety Culture redux
>  
> There are often nuggets of insight on this mailing list and also some amount of noise.  This debate on bugs versus defects has been no different.  I found this post from Les to be very much the former and I just wanted to say thank-you.  There are insights here I intend to put to work immediately in the training I provide. 
>  
>  
>  
> Sent from my Verizon, Samsung Galaxy smartphone
>  
>  
> -------- Original message --------
> From: Les Chambers <les at chambers.com.au>
> Date: 2/26/18 7:25 PM (GMT-05:00)
> To: systemsafety at lists.techfak.uni-bielefeld.de
> Subject: [SystemSafety] Safety Culture redux
>  
> Hi
> 
> I started this thread referring to the Harvard Business Review, Jan-Feb,
> 2018 reflections on culture. I was referring to the definition of culture.
> This is only half the story. At the end of the article there are some
> thoughts on " 4 levers for evolving a culture". Here are my thoughts on the
> how-to as applied to software development - in the context of the preceding
> discussion on bugs and defects. 
> 
> The skinny on the '4 levers 'from HBR is:
> 1. Articulate the aspiration. Talk about attitude change in the context of
> real world business imperatives.
> 2. Select and develop leaders who align with the target culture. Your
> leaders have to walk the walk - be exemplars of required cultural norms.
> 3. Use organisational conversations about culture to underscore the
> importance of change. People need to be given time to discuss and reflect.
> 4. Reinforce the desired change through organisational design. Your
> organisational structure should allow people to contribute, top-down and
> bottom-up.
> 
> So thinking it over:
> A seatbelt can save your life but only if you are wearing it.
> The software engineering body of knowledge is also a wonderful thing but it
> will not further the cause of humanity if developers don't buckle up.
> All the posts on this subject seem to be saying, "Let's make this BOK more
> beautiful, more precise, more shiny; if it's logical they will come." This
> is classical engineering thinking, defining the world not as it is but only
> as it should be relative to us. We persist in taking our logical knives to
> cultural gunfights; ignoring the reality that "culture is inextricable from
> the emotional and social dynamics of people in the organisation"[Harvard
> Business Review, Jan-Feb, 2018].
> My point is that persuasion is required and this is a whole different field
> of activity; one that is not wholly informed by logos. How do you convince
> someone to embrace a discipline? We don't know. I submit that we should
> know. Foxes hypnotise cats by swaying in front of them. All engineers should
> be part shaman. We're already dealing with advanced technology that is
> 'indistinguishable from magic'. It should be second nature.
> This is an important social issue. I hold it to be axiomatic that: 
> "In the limit everything is become software." Every day it seeps further
> into more critical aspects of our lives. But we lack the skilled people to
> create it. It will therefore be the work of unskilled developers. This is
> creating an unstable society.  
> In 43 years of attempted persuasion I've noticed that culture change doesn't
> happen without a compelling reason. And the more complex and rigorous (and
> expensive) the target discipline the more life and death the reason has to
> be. 
> Try:
> 1.      If you don't follow proper process you can't work here any more.
> 2.      If this system is hacked the company will be out of business.
> 3.      Do you want to be personally responsible for killing someone?
> 
> In contrast. If you call it a "bug" instead of a "defect" what evil will
> befall you. None. 
> 
> The case for culture change therefore needs to be unambiguously tied to
> tangible problems, company strategy, personal ambitions, required outcomes ,
> consequences and avoidance of unfortunate events  - for us, death. History
> has proved we react well to existential threats. We tend to snooze when
> reading dictionaries.
> 
> So I return to the code review. Yes it can find defects in code but it's
> higher purpose is "cultural event". To show by example the thought processes
> that are acceptable around here and those that are not. Senior people become
> exemplars. There is discussion on why code quality is important. 
> 
> So what other cultural events do you run that give people pause to reflect
> on the life and death necessity of discipline? 
> 
> Shamans persuade through metaphor and story. It's black magic. The legend of
> error 1202 comes to mind. Sway while you tell it. The good shaman knows
> that:
>     they never remember what you say only what they were visualising while
> you were talking. 
> 
> A colourless tech term won't cut it, you need to put images in their minds.
> Neil Armstrong, 384,000 km from home, thrusters kicking up moon dust, 20
> seconds of fuel remaining, looking for a place to land. Don't explain,
> dramatise.
> 
> The secret persuasive sauce in storytelling is "aesthetic emotion". 
> DEFINITION (ha ha)
> Aesthetic emotion is an emotional response to a situation when thought and
> feeling come together to create meaning. "When an idea wraps itself around
> an emotional charge, it becomes all the more powerful, all the more
> profound, all the more memorable. ... It harmonises what you know with what
> you feel ..." [Bob McKee, Story] 
> Steve, how do I get this into IEEE 610. Can I fill out a form?
> 
> We experience aesthetic emotion while watching a movie. We don't have this
> experience in normal life. The thought and the emotion come to us
> separately, we have the experience then reflect on it later and through this
> reflection our attitudes change. Most enduring attitude changes come from
> lessons learnt in blood. But a good story well told can convey the lesson
> without the blood. 
> 
> I am an advocate for code review because very early in my career I failed to
> implement a rigourous code review process with inexperienced programmers and
> nearly destroyed $6,000,000 chemical reactor. That was the year that made me
> - 1981. An emotional experience, fortunately a near miss, but it could have
> been a career ending event at age 33 for a kid that never wanted to be
> anything else but an engineer since the age of 11. I've reflected on it ever
> since. So there you go, the idea that code reviews are good wrapped around
> an emotion - fear of career death. This experience turned the code review
> process into a religious rite for me. Don't let me catch you skipping code
> review, I'll come over and let down your tyres!
> 
> So the dog's bark but the caravan moves on. I recently spent some quality
> time amongst good people. They write software that fires missiles. Frankly I
> wasn't telling them anything they didn't already know but we had fun
> reviewing the BOK and playing with the pencils on the bench. One thing they
> told me was depressing. It turns out that the youngest guy in their shop is
> 40 years old. They can't retain young people. What they're doing is viewed
> as "... it's like sooo uncool ..."
> 
> This is the essence of the problem for the future of the planet. And we
> won't solve it by slinging a dictionary at these kids. So I'd encourage the
> engineering profession to think bigger and search wider. Let's pull our
> collective heads out of tech and put more think time into what feeds the
> soul - where the attitudes live.
> 
> Les
> 
> --
> Les Chambers
> les at chambers.com.au
> +61 (0)412 648 992
> 
> 
> 
> 
> _______________________________________________
> 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/20180301/da1ac4c3/attachment-0001.html>