Archive for the ‘Uncategorized’ Category


The Gorilla Process Conundrum

November 17, 2014

There is a story that is told to show us how we all behave stupidly in corporations

  1. Place five gorillas in an outdoor cage in a cold, windswept location.
  2. Suspend a banana in the cage above a ladder.
  3. When any gorilla attempts to use the ladder, soak all five gorillas with a fire-hose.
  4. Repeat until they avoid the ladder. After a short period of avoidance, replace one gorilla.
  5. Note that when the new gorilla attempts to use the ladder, the other gorillas will beat him up. Take the fire-hose away.
  6. Repeat step 4 until all original gorillas have been replaced.
  7. Note that at this point, no gorillas use the ladder, any that try are beaten up, and none of them knows why.

…and aren’t the gorillas all stupid and everything for being unpleasant to each other for no reason.

The cheeky bit in this story is that little bit at the end of step 5: we know the fire-hose has been taken away but the gorillas don’t. People who have more information than others should not feel they are being clever, or the others are being stupid, when the difference is merely who has been told what.

If we keep the fire-hose with intent to use it, then the moral of the story becomes very different: the gorillas as a group are behaving in a way that keeps them dry even if they don’t know why.

Which is one use of process. We can follow process without requiring deep understanding, and that means in practice we can quickly learn ways of working usefully before finding out why it’s better to work that way. Once we know the work and the team well enough, then we can – and should – challenge poorly understood process.

That is, there are of course problems with simply accepting process or traditional practice, but there are also problems with letting every new gorilla climb the ladder to find out for himself: it takes time, and everyone gets wet and cold and miserable.

Many skilful tasks can be reduced to a checklist for routine use. For example, deploying webapps to Weblogic can become a routine task and there is no need (or wish!) for a skilled Weblogic guru to do this simple task when it can be written on a list and given to ‘junior’, cheaper staff, leaving the expert to work on other things.

Having a check list improves organisation capability and reduces effort. Coders whose attention is on building applications to solve difficult business problems can work from that checklist to to deploy their work themselves, without also having to learn the quirks of this particular web container or wait on the expert The checklist will tend to be written for simplicity and readability, so may contain some redundant or long-way-around methods. As odd problems arise, extra steps may be introduced (such as routinely restarting the container) that are not strictly necessary. It is not the ‘correct’ way to deploy, but a pragmatic one.

The list can be distributed without the expert which can be useful for quickly gaining capability, or can cause failures where they are not appropriate and people have referred to the list rather than look up an expert for their particular problem. The expert might leave out of boredom when all the challenging setup work has been done, or be ‘leaned out’. In both these cases we now have a checklist, or process, without the expertise to monitor it or review it. Workarounds are added by ill-informed rumour and the process gains warts and weights. Business needs change and the tools change, and process users attempt to shoe-horn them into the process, because there is no-one around to review it, or even authorise change to it – or worse, there may be people around whose job it is to enforce use of it, without understanding it.

Discarding process at any excuse is also not helpful as people then continuously relearn tasks, and the mistakes of the past, to a depth that exposes the reasons why the discarded process is the way it was.

So where then is the happy medium? An organisation should be willing to challenge process by the users of that process. It should have, ‘close’ to that process, experts who can carry out the technical arbitration when process users want different things from it. And the risk holders must be aware that not changing a process might be more harmful than changing it.


Holidays and Engineers

October 24, 2014

It was holiday season and staff all over the place were going away and coming back a couple of weeks and lots of miles and unfulfilled dreams later. Everyone had forgotten to plan holidays into the schedules, and all sorts of key knowledge was away on the beach getting soaked in bubbly or gin, or high in the mountains getting altitude sickness, or somewhere steamy getting cerebral malaria. Those minions left behind flit from crisis to crisis, usually head-down in the detail, and working through those incremental changes and discussions and events and reasoning that those away are blind to in their holiday-bubble-bliss.

So when they come back, feeling like they have lived for years on a different planet, there is always some reconciliation and adjustment.

For returning seniors this is easy. Usually they expect things to continue according to plan, which of course they never have. “Why isn’t it different?!” they roar, and I shamelessly cower shamefully beneath their fury and whine “But sir! Without the tingle tangle of your invigorating lashes, smarmy-smarm, how can we work without you? toady-flinch” and they swear undying punishment and spit fiery acid and depart, mollified by this proof of their motivational powers, to make a new Action Plan and Move the Dates to the Right.

Returning engineers are more tricky. Engineers expect things that ‘belong’ to them – the things they look after, or have created, that are therefore personally theirs – to remain the same. It doesn’t matter if they knew it was a bug-ridden fragile morass of spaghetti code, or if they’d not even finished it, or even if they’d only just started sketching out some ideas. Beware anyone who has touched it, let alone written a replacement! “Why is this different?!” the returning holiday-enhanced minions cry, aghast at the Unexpected Thing that occupies their gaze. “This was working fine!” and “We agreed to do it my way!” they outrage, being free with the meanings of ‘this’, ‘working’, ‘fine’, ‘we’, ‘agreed’ and ‘do it my way’.

The usual response by the bitter, tired and holiday-less minion is personal and tactless: “Your stuff wouldn’t work” to which the outraged minion replies disbelievingly “Oh yes? What was wrong?” followed by a short verbal debug, an outline of why it was stupid to try using it that way, barely veiled assertions on each other’s appalling lack of skills, and further discussion until Huff.

Tact can only add a single step to the start of the sequence, such as the impersonal “We couldn’t get the existing set to work” to which the returning minion cries “what, my stuff?” and the discussion continues as without tact.

About the only useful mollify is to blame external factors or teams: “We were tasked to provide the outer nodule with more kahoobles so we had to do it this way” at least brings on Straight Huff, possibly with faint “This could have done it” whine, and reduces the shouting.

I’m going on holiday soon. Don’t Touch My Stuff.


Obvious deficiencies

June 25, 2011

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.

The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature.”

– Tony Hoare in his Turing Award speech, 1980