The Problems of Mikhail Bongard

"The Men in the Moon: or, the 'Devil to pay.' With thirteen cuts [by George Cruikshank], etc. [A satirical poem-chiefly in reference to the proceedings of Messrs Cobbett, Hunt, and others.]"

This post is thinking in progress. I’d love feedback.

 

 

 

How we are educated to become problem solvers

We learn problem-solving by looking at problems that have solutions. This is how our success at problem-solving is measured in school. If we’re lucky we can look in the back of the textbook for the answers, and figure out how to work towards them. This cuts problems in half, like starting to dig a tunnel at each end and hoping to meet in the middle. Starting from a question and an answer we’re simply filling in a method to get between the two. If we do well at this we call ourselves ‘problem solvers’ on our CV..

What are Bongard problems?

Mikhail Bongard invented visual pattern matching problems that reverse the normal style of the problem to be solved. We usually have a question and the answer needs to be found.

Bongard problems give you the answers, and you need to figure out “what’s the question here?”, “What’s happening?”.

From Wikipedia

The idea of a Bongard problem is to present two sets of relatively simple diagrams, say A and B. All the diagrams from set A have a common factor or attribute, which is lacking in all the diagrams of set B. The problem is to find, or to formulate, convincingly, the common factor

An example Bongard problem, the common factor of the left set being convex shapes (the right set are instead all concave).

From Godel, Escher, Bach

When looking at Bongard problems, we can look at the solutions to previous problems and build a list of potential answers to search through, as in the example below.

 

How did we get here, and where are we going?

Bongard problems ask – how did we get here? This is a significant difference to normal problem solving, but it gets better.
Working in a complicated domain, such as fixing problems in IT systems, we’re often asking “what needed to happen for this problem to occur”? Knowing this, fixing the issue is relatively straightforward, but not always easy. Things can still get very complicated, but it’s all potentially knowable.

Working in a complex domain (listen to Dave Snowden talk about complexity), which means any time when people are involved, what happened last time we did X may not have the same results this time.

So in complex domains,  why do we even care how we got here? I’d suggest because understanding how we got here may help us understand how the system we’re looking at is disposed to behave and because the modelling will require us to think hard about the issues (I can’t find a source for this).

How do we think hard about Bongard problems?

Bongard problems obey Occam’s Razor – “among competing hypotheses, the one with the fewest assumptions should be selected or when you have two competing theories that make exactly the same predictions, the simpler one is the better.” (https://en.wikipedia.org/wiki/Occam%27s_razor)

Douglas R Hofstadter describes a process for solving Bogard problems in the epic book Godel, Escher, Bach. (Godel, Escher, Bach: An Eternal Golden Braid, Basic Books, Inc. New York, NY, USA ©1979 p646)

Bongard problem solving would have several stages in which raw data gradually gets converted to descriptions.

  • Raw data preprocessed
  • some salient features are detected
  •  The names constitute a mini vocabulary
  •  Drawn from a salient feature vocabulary
    •  line, segment, curve, horizontal, vertical, black, white, big, small, pointy, round.
  •  Second stage of preprocessing
    •  Triangle, circle, square, indentation, protrusion, right angle, vertex, cusp, arrow

 

  • Now the picture is ‘understood’ to some extent tentative descriptions are made
    • above, below, to the right of, to the left of, inside, outside, close to, far, parallel, perpendicular, in a row, scattered, evenly spaced, irregularly spaced
    •  Numerical descriptors
  • More complicated descriptors
    •  further to the right, less close to, almost parallel to

Hofstadter introduces an idea of a “description schema” or “templates” and the idea of “Sam” – a sameness director to help to solve Bongard Problems.

This is where I am. I think it’s possible to create a useful description schema or Sam for our real-life problems, using the systems approaches I’ve written about elsewhere on this blog.

Description schemas are types of weighted directed graphs, similar to the graphs used behind online recommendation engines. I’ve got a new job involving ontologies and graphs. Thanks for Ivo (@kvistgaard ) and Julian (@julianfej ‏)for help getting started with the ideas behind linked data. More work to come here.

Advertisements

Strengths and Clean Language Workshop #3

The Strengths and Clean Language workshop met weekly for a year, and then had 2 months off. Meeting again I was full of ideas that seemed to fit really easily. The workshop was Mike, Tomasz, Sarah, David and Richard.

I found a draft of this post from early 2107, and published it in December 2017.

We started off with the quote from Miles Davis. I’d been at a SCiO Systems Thinking Open Day, and I stole this image from Arthur Battram. Arthur’s presentation on the links between Miles Davis, Jazz and complexity and systems thinking was delightful. And he has a jazz hat. Arthur’s book is great too.

Organisational Metaphors

On the train home from SCiO I was reading Images of Organisations, by Gareth Morgan. This book discusses how Organisations, can be seen through the lens of eight different metaphors at the same time. Each metaphor will reveal and hide different behaviours and systems.

Gareth’s book is referenced in Open University Systems courses, O’Reilly’s Cloud Technology book Architecting Microservices, on Clean Language coaching websites, and is one of ribbonfarm.com’s recommended books. Too say that it’s influence is wide and varied is an understatement. It’s also usually less than £3 on ebay.

I’ll borrow Venkatesh’s overview of the metaphors that Gareth Morgan uses from ribbonfarm.com.

Organization as Machine: This is the most simplistic metaphor, and is the foundation of Taylorism. Any geometrically structuralist approach also falls into this category, which is why I have little patience for people who use words/phrases like top down, bottom-up, centralized, decentralized and so forth, without realizing how narrow their view of organizations is. The entire mainstream Michael-Porter view of business is within this metaphor.
Organization as Organism: This is a slightly richer metaphor and suggests such ideas as “organizational DNA,” birth, maturity and death, and so forth. I really like this one a LOT, and have so much to say about it that I haven’t said anything yet. I even bought a domain name (electricleviathan.com) to develop my ideas on this topic separately. Maybe one day I’ll do at least a summary here.

I introduced Gareth’s metaphors and the Miles Davis quote.

We’re heroes in our own story

Sarah commented ‘We’re all heroes in our own story. The way we look at things makes sense of thing so that we’re central in the story, and our actions make sense. Our (Clifton) Strengths may influence the story we tell. It story may also influence the metaphors we use to  understand and talk about the organisations we’re part of.’ Hero’s of our own story is something we’ll come back to. And as Miles says, if you understood my story, you’d be me….

Sarah also noted how she is interested in the perspectives of some metaphors, like the political system metaphor, but doesn’t like to get involved in politics, it wears you out.

We (well I) jumped to clean language here. I’m particularly interested in Clean Scoping Questions. The scoping questions are used to see if a Clean Language approach, usually revealing uncomfortable behaviour patterns, is wanted by the coaching client. Rather than face their own patterns, the client may just want a “diversity certificate”, or similar.

A quick overview is

What do you want to happen?

What needs to happen so that <answer to what you want to happen> is automatic?

What is happening right now?

The answer to what is happening right now usually contains unhelpful patterns of behaviour. Before looking at the patterns, we talked about how asking the question “What needs to happen so that what you want is automatic”, could be (uncleanly) asked in the context of Gareth Morgans metaphors.

So, “thinking about the situation using the brain metaphor, what do you want to happen?”

Or “thinking about the situation using the organism metaphor, what would you see and hear when <what you want to happen> is happening”.

I think we may try these questions in the group to see what occurs.

As a group we’re all familiar with the unhelpful reflex patterns of behaviour described by Barry Oshry, and the alternative ‘balcony’ behaviours that we can use if we see the reflexive patterns in time.

In her book “From Contempt to Curiosity” Caitlin Walker describes using the Karpman Drama triangle to describe a set on unhelpful behaviours “Persecutor, Victim and Rescuer” that are seen in Clean Scoping. These patterns map really well onto Barry’s TOP / MIDDLE / BOTTOM behaviours we describe in Balcony and Basement terms.

Sarah suggested that people’s Clifton Strengths may influence the organisational metaphor they prefer to use – they’ll see the world in a way that sees their strengths positively.

There were some similarities between the Karpman Drama triangle behaviours, and the basement behaviours of TOP/MIDDLE/BOTTOM, Richard noted an overlay of balcony behaviours onto the Drama Triangle, making it a hexagon. The drama triangle seems to describe behaviour more easily the TOP/MIDDLE/BOTTOM, but Barry’s Model is a lot richer.

Each of the patterns on the Karpman Drama Triangle maps to Basement behaviour of TOP’s MIDDLEs and BOTTOMs. We noted how you can see Victim, Persecutor and Rescuer behaviour in TOP, MIDDLES and BOTTOMs.

A TOP who take responsibility because they feel they are removing their help from someone is engaging in victim behaviour. MIDDLES who side with one person over the other may be PERSECUTING one side of the other, before moving to victim and rescuing.

We had a good workshop, getting new approaches that increase our variety, allowing us to describe more situations and behaviours.

If you understood everything we said, you’d be us.

 

 

 

 

Know Yourself with a User Manual for You

Title: "The Adventures of Sherlock Holmes", "Single Works" Author: Doyle, Arthur Conan - Sir Shelfmark: "British Library HMNTS 012634.m.7.", "British Library HMNTS Cup.410.g.93." Page: 275 Place of Publishing: London Date of Publishing: 1892 Publisher: G. Newnes Issuance: monographic Identifier: 000977457This post uses a set of questions, called “User Manual for Me“, by Cassie Robinson. (ht Mike Watson @herdimmunity)

Cassie’s idea is that answering a set of questions about how you prefer to work and interact with people lets people can help you work together better. In an ideal world, you’d know more about people around you, and they’d know more about you.

These questions seem ideal for framing as clean interviewing questions, with following clean questions that can help the client get deeper knowledge of themselves. They can choose to share these insights with colleagues of not.

In this post I answer these questions for myself, and then suggest contextually clean following questions that could be asked.

 

Warning Required?

I’ve had a mixed reaction when talking to friends and colleagues about Cassie’s questions, which all came down to safety. If you’re in a team and everyone wants to do this it would be great. If there is anything like hostility this soft of thing in the team then it’s not something people seem happy about. If you’re in charge, don’t force this on anyone.

Warnings aside, if you’re in a good team, or want to know this to share with a few colleagues then these questions are excellent in helping others understand you.

In this post I’ve suggested contextually clean versions of the questions, and contextually clean follow ups questions to my answers.

What are Contextually Clean Questions?

Clean Interviewing is a way of asking purposeful questions that contain a minimum amount of the questioners thoughts, ideas, opinions and suggestions. These questions are contextually clean.

Clean Interviewing allows the client to express their understanding with the minimum influence from the questioner, and can lead to unexpected insights.

More information is on the Clean Language Wikipedia page which has been recently updated by James Lawley.

The contextually clean versions of the questions pretty much wrote themselves. Cassie’s heading were pretty clean already. I’ve added some contextually clean follow-up questions to my own answers in green, as an example of how the User Manual questions could be followed up with contextually clean questions.

By Cassie Robinson

My Answers and some potential follow-up questions

Contextually Clean follow-up questions in green.

Conditions I like to work in.

(Contextually Clean Question: What are the conditions you like to work in?)

I need variety. I get ideas by talking to people and hearing their ideas and perspectives. The conversations don’t need to start with the goal of having an idea. I like face to face interaction.

Is there anything else about the ideas from face to face interaction?

If I’m reading detailed information, or doing technical problem solving then I work best alone, but I need to get feedback on my work if I’m not making progress. I can stubbornly bang my head against a problem for far too long. It’s effective, but perhaps not always efficient.

(There is already a contextually clean question about feedback later.)

I need to read and annotate paper copies. I don’t read or understand well off a screen. Sorry trees.

I move around to get unstuck, or if I’ve got something to think about. I work well on the move.

Are some ways of moving better than others?

Is there anything else about getting unstuck?

The times/hours I like to work

(Contextually Clean Question: What are the times and hours you like to work?)

I start thinking early, when I wake up. I re-run what I learned the day before, and plan for the day before getting out of bed. Cycling to work is time when I work through problems, so I arrive primed. I then really like to make progress. Meetings and major task switching here can really stop progress for the day.

What happens when you re-run what you learned the day before?

Is there anything else that needs to happen before you’re primed?

After lunch I’m better at discussing ideas and meetings, unless I already shared the ideas I had in the morning. Mid afternoon I get a second window to work well on technical problems.

Is there anything that needs to happen before the second window to work on technical problems.

I read and write well in the mornings and evening, from 9.30 till about 11.15pm.

If something is difficult and interesting enough I’ll be mentally working on it all the time…

What makes something interesting enough for you to be mentally working on it all the time?

The best way to communicate with me

(Contextually Clean Question: What way of communication is best for you?)

I like communication to be in person, followed by a written overview of any actions I have. I work best if I understand your purpose, and goals. I’ll figure out the best way I can help you reach them.

How do you like someone to express their purpose and goals?

How would you figure out the best way to help?

I’ll also tell you if I can’t make sense of your purpose and goals. I’m good at juggling multiple perspectives, so I like these perspectives to be in the open.

The ways I like to receive feedback

(Contextually Clean Question: How do you like to receive feedback?)

I like feedback to be quick, and to include context. Face to face feedback is best, as I can misunderstand written feedback easily.

I like feedback to focus on what I did, and ideally to  suggest areas for improvement, without being prescriptive. I’m continually increasing my understanding of how I work and learn. I need feedback for this.

Things I need

(Contextually Clean Question: What do you need to be at your best?)

I need to understand purpose. I’m not the best at following a process, without understanding why. I may need someone to listen if I have an idea for improving a process too. That’s what I’m good at.

Where do your ideas for improving a process come from?

I need to be trust to do the right thing. I sometimes express an idea that doesn’t seem to follow from the facts. I need people to ask me to fill in the gaps in my thinking and explanation.

Where do the ‘gaps’ in your thinking and explanation come from?

I need something to be curious about.

What’s that curiosity like?

I need reminders for things I may have forgotten, and for people to ask how it’s going.

Things I struggle with

(Contextually Clean Question: What do you find difficult? I think the difficult is cleaner than struggle..)

I struggle following a process, and using ‘we just followed the process’ as an excuse when we knew there were problems.

When following a process, what would you like to have happen?

I struggle with making sense of dense text when a diagram would work better. I may miss an important point if it’s hidden in lots of unimportant text.

My short term memory is almost non existent. it’s not a reflection on my intelligence.

Things I love

(Contextually Clean Question: What things do you love?)

I love

  • a challenge
  • designing and building things that other people find useful
  • learning and making useful connections between ideas
  • The ‘aha’ moment when something clicks
  • bullet points
  • helping people with the things above, and solving their problems

What happens before you build something people find useful?

Other things to know about me

(What would you like people to know about you?)

I need to draw something to explain it to you. Even if there is a perfectly good drawing in front of me, I need to draw it again while talking.

I like ideas. I can sometimes be a bit enthusiastic. I like to talk.

I can often quickly analyse a situation, and figure out a course of action, or the events that led up it. I can think this much quicker than I can articulate why. I quickly model situations, and run accurate scenarios against them.

Extra Question Suggestion

How I learn things

(Contextually Clean Questions: How do you learn things?)

I learn things best when they extend something I already know. It’s like a need a hook to hang new information on. I also need to learn the principles, context, and any constraints to the information or tools I’m using. When I learn things I’ll remember them by understanding the principles and context, rather than the facts and process.

How do you get hooks to hang new information on?

I’ll learn something new by relating it to the information I already have, and any similarity of context, patterns or constraints.

 

I hope to ask these questions with friends and colleagues soon.  Know Yourself is a popular phrase in philosophy and I think Cassie’s questions, followed up with Clean Interviewing questions is a great way to start knowing.

 

Caving with Plato

IMAG1229

The Squares have uniform colour but are not flat

I recently spend a morning at The Design Museum in London. The Breathing Colour exhibition by Hella Jongerius was great. There was a quote from the guide “A Shadow Philosophy” p24 Breathing Colour, Hella Jongerius. It links Plato’s philosophy to the work on our perception of colour.

We don’t see colour in an unbiased way. Lighting, shadows and materials all affect how we see things in the world.

Plato’s Cave; Understanding of the world is derived from shadows cast on the wall from passing objects. The shadows are the prisoners reality, not the objects that cast them. The prisoners have no experience of real objects, and yet they give names to them, and extract an understanding of them, purely from the shadows.

If they step outside the cave and see the real world, they cannot go back. Their colleagues in the cave would not believe them of the world outside.

Outside in the Real World

Those outside see a true world, and it’s so much richer, with only the shadows cast by reality being seen by those in the cave. How privileged we are to see the world as we do.

What we see of the world outside is seen through our biased lenses. There is so much we can’t see, either because of a physical bias, like the spectrum of the wavelengths we see and hear, or because we can only really see the things we have name for, that make it through our cognitive biases, because they are unusual, and we’re paying attention. Or maybe they reinforce what we believe.

We cannot ‘see’ things that we cannot name. To understand new things we need a new language. Knowing that our perceptions are biased we should seek out as many viewpoints that use different language to describe what is seen if we care about getting out of our cave.

Caves all the way down

We should also know that outside of our cave, we’re just in another cave, seeing and talking about things that people who never left the old cave can’t comprehend.

The understanding we get from the shadows on the wall of our cave are all we have, and all we can have. We’re working with our limited and biased information receptors, and we can only see using the bandwidth provided by our current lens, our current cave.

Limits of Metaphors

Metaphors revel and conceal insights. Their power is also their weakness. When writing this I first used the metaphor of the cave ‘above’ and ‘below’. Above / Below suggests a hierarchy of caves and knowledge. This made me feel uneasy  with above being better and below worse, and there being a top cave. So I changed it to say different. I feel happier with this. There isn’t a place where we can see see reality outside of our biases.

In fact, Anil Seth argues that our brains hallucinate our reality. Reality is our brains filling in the gaps in the limited information we have.

What we perceive has as much to do with out internal pattern matching than what is received though our receptors. Our internal pattern matching depends on the patterns we’ve matched before. Ouch, we’re locked in our cave.

This has big implications when talking to others about our ideas, and we are looking for the right thing to do. How do we know when we have enough ways of looking at things?

This short video on Plato’s Cave below suggests that people get angry when their ignorance is pointed out. Plato was killed for his beliefs, and he likes pointing out other people’s ignorance. It could be that a perspective that makes you angry is the one that you don’t want to be without?

When we’re looking to make or suggest the right thing to do, how can we know we’ve got enough perspectives?

Critically challenging our understanding

An approach called Critical Systems Heuristics (CSH) may help us to systematically challenge our perspectives. CSH asks us, and the people affected by the situation to challenge the decision boundaries in use for proposed action. Asking are these shadows on the wall sufficient? Do I need to go to a different cave?

In CSH we get others to answer the same questions we’ve answered and we see the differences.

This diagram from Sjon van ’t Hof shows how we can question motivation, power, knowledge and legitimacy.

csh

I’m suggestion that there is no correct answer to the question of how many perspectives. There isn’t a hierarchy that can be scaled, but we can be critical of the decisions we make in a repeatable systematic way, and be open to challenge.

There may not be a reality out there, but we can still try to understand and act in the best way we can.

 

 

 

 

 

Clean Interviewing for Technology conversations

giraffe, chris barbalis.

Alternative title:

Writing Software, hardest job in the world, 40 years man and boy…

Writing software that meets people needs, that is.

What’s the problem with just talking to people to find out what they want?

When we talk to people, we use shortcuts that help us to understand. We assume that what the other person means by, say ‘website’, ‘connection’, ‘usability’ or even ‘tested’.

Shared understandings can work fine, but very often problem arise when we think we have an understanding that isn’t there. Meetings can start and finish without the attendees really understanding the models in each others heads, and spend time discussing their unknown lack of understanding, rather than the pressing concerns.

Perhaps the HIPPO (HIghest Paid Person in the rOom) gets the last say, based on their unexplained model?

We let the things in our head get in the way of understanding the things that we’re trying to understand in other people’s heads. It’s our brains relentlessly finding patterns and connections to make life easier for itself. We need to act differently.

Clean Interviewing

Clean Interviewing, rooted in David Grove’s Clean Language, is a way of structuring conversations in a way that is incredibly effective in finding out the information inside someone’s head, without influence from the stuff in your head.

Alongside the questioning is the approach to questioning that is best describes showing curiosity towards a person or situation.

When talking to other people we often think that our stuff is like their stuff. Our idea of something is the same as theirs. This is great quick social glue, but if we are coaching someone, or trying to find out something in particular , our unknown lack of understanding can get in the way.

Think of an Elephant. (Or a Website).

An example of this is to ask a group to “think of an elephant”, and then ask them to describe their elephants. None will be the same, some will be close up, or cartoon elephants, or an elephant in a specific place. Questions like ‘Hear Music’ or ‘Think of an ideal day at the beach’ also show how we can really not know what someone is thinking. If you asked me to organise an ideal day at the beach for you, you may not get what you like. You’d get what I like.

Unlike coaching, when we’re interviewing, the interviewer gets to decide the purpose of the conversation. There is an agreed subject to discuss, and this will often be something that has happened in the past, or will happen in the future.

In technology, I’ll suggest Clean Interviewing helps:

  • Discussing the model in the customers, product owner and  develops head
  • In Incident postmortems to discover what happened in safe environment
  • When reviewing work, looking for what went well and lessons learned
  • When getting requirements from a customer for software

 

So what is Clean Interviewing?

Clean Interviewing is a style of asking questions that have roots in Clean Language questions designed by David Grove. Davids questions remove the model, ideas and worldview of the person asking the questions.

We can use Clean Interviewing when we want to find out about

  • Someones favourite holiday destination
  • The needs they would like to have met with software
    • Their goals
    • The way they work with others
  • Their ideal
    • Team
    • Programming Language
    • Work Environment

Examples of Clean and Contextually Clean Questions

A contextually clean question takes the basis of a clean question for example, keeping the speakers context out of the question, and adding the exact words used in the answers.

  • Is there anything else about that X
  • What happens before X?
  • ..and that’s X like what?

Clean Interviewing adds context that is known by both parties, so you can use words used by the other person, or are known in the context of the conversation

So for discussions about developing a new website

  • What happens before people get to your website?
  • Is there anything else about a customers order?
  • and what happens before a customers order?
  • and that’s interactive like what?
  • and is there anything else about that data?
  • and that’s a customer journey like what?
  • and that’s individual user experience like what?
  • Is there anything else about individual user experience?
  • (and for people who know me) ..and that’s digital like what?

The words in italics are the interviewees own words, or things that are known in context of the conversation.

Of course you cannot have all the questions lined up before you start, you’ll use the words given to you to build an understanding of someones mental model.

Writing Software, hardest job in the world, 40 years man and boy, etc

Software is a set of instructions, running on a machine that follows instructions really well. It’s the ultimate machine. The code never gets tired, or goes rusty, or deviates from the configuration. This is powerful.

People wanting software to meet their needs have models in their head of their problem and solution. Those models can be incomplete, or unconstrained by reality. In an agile Scrum team it’s the job of the Product Owner and the developers to build something that meets the customers needs.

I’d suggest that this is much harder than for example tailoring clothes or even writing a song for someone.

Bridging the gap between the models in someone’s head, and the constraints of software is a huge task. Clean Interviewing can help with understanding requirements.

This post was inspired by a session at Northern Taste of Clean, facilitated by James Lawley and Caitlin Walker..

Northern Clean: 2017

There was a lot happening at “A Northern Taste of Clean”. This is what I learned:

I build models to feel in control. This means  I sometimes need to stop building models and get into the real world, and this may feel hard.

I’ve found a path, and I’m following it. I don’t know the destination, and that’s fine, since I trust myself to make good decisions where to go next. I also have great friends who help me.

What I do to find new things to learn is different from what I need to do to learn them. I need to develop a machine like process for learning specific things. This will stop me ‘spinning my wheels’ when I should be getting on with things.

My tapping foot is telling me I need to move to have ideas. I work best on the move, or when I am ‘somewhere’. (I did 3hrs reading/writing on the train home…)

I need to know when I’m on the Drama Triangle, were other people are, and understand what I can do.

I build models feel in control, and compensate for my lack of short term memory. I can feel really out of control when I don’t have an understanding of what is going on. (So I should get to places /events early,  have phone numbers / directions sorted, get written timetables.)

Learning and teaching Clean Language and Modelling enables anti-fragility.  Learning to model means you can grow, understand your patterns, be anti-fragile.

You can’t have outcomes faster than the speed of trust.

You may have multiple allegiances or reasons for questioning. Know why you are asking each question.

I make expensive decisions sometimes because for me, the alternative is to do nothing, not to plan how to do things cheaper.

I’ve got power and control, it can be used, and wasted.

I’m a novice at this.

The clean community are lovely. I’m happy to be a part. Thanks to everyone who made Northern Clean possible.

Thanks to David Grove for creating something amazing.

DevOps Metaphors in a Nutshell.

Image from ribbonfarm.com showing Gareth Morgan’s 8 Organisational Metaphors

This is the first DevOps post on make10louder. DevOps is a way to develop and run software that removes organisational boundaries and shares tools and culture.

DevOps is similar to a marketing and sales department working closely with factory operations to make sure the factory can build and deliver what the customer wants.

TL;DR

This post looks at the different types of work in building and running software. I’ll suggest organisational metaphors reveal useful insight into DevOps; removing the boundaries between development and operations, and delivering value to customers. We can work better from understanding all the perspectives these metaphors give us.

Gareth Morgan’s Organisational Metaphors

The organisational metaphors I’m using are from Gareth Morgan’s Images of Organisation. (This book referenced by Microservices Architecture , coachesOpen University MSc courses, and ribbonfarm.com).

There are eight metaphors; Machine, Organism, Brain, Culture, Political System, Psychic Prison, Change and Flux and Instrument of Domination. All the metaphors can be true at the same time. People are likely to favour a dominant metaphor in their understanding of the organisation. This means the organisation will be working in ways they cannot see.

The metaphors that I think Devs Ops uses are:

  • Organisations as Machines
    • with known input they should produce identical output
    • ideally ‘well oiled’
    • People as interchangeable cogs, once trained or certified
    • Input, process, output.
    • reducing variation
    • A leads to B leads to C.
  • Organisations as Brains
    • Who knows what
    • How information spreads
    • Constant learning through feedback, and learning to learn
    • Viable Systems and management cybernetics
  • Organisations as Organisms
    • Adapting to the variety of a changing environment
    • Evolving an organisational DNA
    • Having a survival strategy
    • the best fit with the environment survives
  • Organisations as Cultures
    • The way we do things here
    • Value Systems
    • Norms and Patterns of Behaviour
    • Dominant cultures and sub-cultures

I don’t see DevOps best practices covering:

  • Organisations as Political Systems
  • Organisations as Psychic Prisons
  • Organisations as Instruments of Domination

There are some useful lessons looking at real world problems through these lenses, that I will leave to another post.

Metaphors in a DevOps World

#1 Computers are actually Machines

This is not even metaphorical. Don’t configure computers by hand. Person A should not configure a computer better than person B. Computers are often still treated like they need configuration by a wizard.

DevOps insists we treat computers like machines, configured accurately by other computers by running code.

This gives us to easily replicate systems, and have reassurances that if something is wrong it’s not because the wrong wizard configured them.

We treat monitoring metrics in the same way. Automate and get data on all the things.

#2 Processes are machine-like, but controlled by Brains influenced by Culture, in a complex unknowable future environment.

We design our process to run smoothly and they’re automated where possible. We have a strong culture of doing the right thing when things go wrong and we learn from our mistakes. With double loop learning we also ask ‘is this still the right thing to do?’

#3 People are not Machines

People are a complex combination of all eight metaphors.

In a DevOps people are give time to learn and apply their knowledge safely. They are given the tools they need and trust to know how to best use them without involving centralised experts. We encourage a culture of experimentation, honesty, shared ownership of problems and customer focus. Machines cannot do these things.

#4 The value created by software can be seen as the output of a machine

The output as seen by the customer is the number one priority. Customers don’t care how parts of the value stream are working. They care about the output of the entire system, and internal optimizations can have negative consequences. Systems Thinking 101.

#5 Working Software is a machine, used by People, in a changing environment

Software, like the computers it runs on is literally a complicated machine. Although software may behave in ways we don’t understand, without AI, it’s knowable and predictable. It may still be incredibly complicated, but it’s theoretically understandable in advance if the starting point, context and inputs are known.

Problems arise when people use the software. We can start to understood people using the metaphors of brains, culture, organisms and a healthy dose of biases via psychic prisons.

We should automate as much of the machine part of software as we can, in the knowledge that the needs of the people using it will take all of our attention.

We can’t automate software development, but using Agile methodologies to move bits of functionality from customers heads into predictable code, we’re riding a flux and change metaphor.

DevOps Metaphors in a Nutshell

Computers are machines. Build them with code, don’t craft them by hand.

Processes are designed and improved like machines, but in the knowledge that bad stuff will happen. Culture will help you do the right thing when it does, and brains will help your organisation improve. As an organism you need to adapt to a changing environment. Today’s solutions are tomorrows problems.

People and Teams can learn and adapt, but can also follow anti patterns. All the Organisation Metaphors help here. Metaphors of Political Systems and Psychic Prisons (think Cognitive biases) may also help diagnose issues where you’re following good practice, but things still are not working.

Software works like a machine in a complex environment including people, and all of their metaphorical ways of seeing and acting. Crossing this chasm is the work of developers often aligned to the agile manifesto. The use a dominant metaphor of flux and change, but produce software that has a repeatable output.

Conclusion, and So What?

Organisation metaphors reassure us we’re looking at the right things and show us how we can more fully understand situations.

DevOps is a mixture of theory and sound practical experience. Metaphorical insight can help us.