[SystemSafety] Safety Culture redux

Thu Mar 1 01:07:20 CET 2018

And furthermore Haim

I'm labouring this discussion but your example is just too good to pass up.
Your example is the first step in the classic why/how/what persuasion
technique where:

Step 1. Why - motivation: you find some emotion that you have in common with
your audience. It's the first step in all seemingly hopeless negotiations.
Find something you can agree upon with your opposition. In this case its
fear of being responsible for someone else's death. In your case you
dramatise this with "the dark" metaphor. All of us have at some time been
afraid of the dark.

Step 2. How - manifestation: how your actions could be informed by your
motivation. In this case if you don't want to be responsible for a death you
could study and practice proper engineering process for developing software 

Step 3. what - some product, process or attitude of mind that can support
your actions. In our case: international standards for best practice in
software engineering AND a life-long commitment to "the discipline" as an
act of faith.

It is unfortunate that most advertising and engineering prose, intended to
persuade, starts at step three without going through one and two, which
explains why it is largely ineffective, especially among nonprofessionals.

More on this at my work in progress: 

Story in Engineering: What story tells us about human nature that will make
us better engineers

http://www.chambers.com.au/public_resources/Story_Tutorial_V4.0.pdf

Refer section 4.3 The Elevator Pitch - Story Throughline

Les

From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Les Chambers
Sent: Thursday, March 1, 2018 7:33 AM
To: Haim Kuper
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Safety Culture redux

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/a8cfeb33/attachment-0001.html>