fishing and refactoring: A story with two endings

The Happy Ending

I'm salmon fishing on the River Spey, on the beautiful Tulchan beat, concentrating on spey casting. My phone is back at the hotel. My laptop is back at the hotel. I'm not thinking about coding. I'm fishing and I'm only fishing. Suddenly, from "nowhere" my subconcious pops an idea up into my consciousness. It says, hey, you know that code you were working on 2 weeks ago...? Where you had that nagging feeling there was a better, simpler solution? I know you know what I'm talking about! We'll I've been working on that for you. And I've come up with this. Here's the idea. Tada. What do you think?

For a moment, I think about the idea. It seems a good one. Of course, I can't try it out now because I'm waist deep in the middle of the River Spey. I promise myself I'll look into it when I get back to the hotel. I carry on trying to catch a salmon.

Later, back at the hotel I try out the new idea. I re-run all the unit tests and they pass. I make the change.

A few weeks later I'm fishing again. This time on the River Tay at Dunkeld. My subconscious pops up a new idea. I make a note of it. In the evening, back at the hotel I try the change. All the tests pass. The change is live.

A few weeks later I'm fishing again. On the River Verdal in Norway. My subconscious pops up with another new idea...

---

The Sad Ending

I'm salmon fishing on the River Spey, on the beautiful Tulchan beat, concentrating on spey casting. My phone is back at the hotel. My laptop is back at the hotel. I'm not thinking about coding. I'm fishing and I'm only fishing. Suddenly, from "nowhere" my subconcious pops an idea up into my consciousness. It says, hey, you know that code you were working on 2 weeks ago...? Where you had that nagging feeling there was a better, simpler solution? I know you know what I'm talking about! We'll I've been working on that for you. And I've come up with this. Here's the idea. Tada. What do you think?

For a moment, I think about the idea. It seems a good one. Of course, I can't try it out now because I'm waist deep in the middle of the River Spey. I promise myself I'll look into it when I get back to the hotel. I carry on trying to catch a salmon.

Later, back at the hotel I think about the new idea. I'm wary of making the change. There are no unit-tests I can quickly run. I'm remembering a few months back - that time when I tried an idea and broke stuff and was castigated. I'm fearful of making the change. I don't make it.

A few weeks later I'm fishing again. This time on the River Tay at Dunkeld. My subconscious gives me a new idea. I make a note of it. In the evening, back at the hotel I think about making the change. There are still no unit-tests. And I'm still remembering that time a few months back - when I tried an idea and broke stuff. Boy was I ridiculed. And if anything the culture is a bit worse since then. I can feel the fear. Once again I decide not to make the change.

A few weeks later I'm fishing again. On the River Verdal in Norway. This time, my subconscious doesn't pop up a new idea.

pair-programming

Here's the slide-deck on pair-programming I recently presented for a client.

Pair programming from Jon Jagger

Atlantec conference

It was a pleasure and an honour to speak at the first Atlantec conference held in Galway, Ireland on May 15th. I talked about cyber-dojo and showed some statistics from a random sample of its 30,000+ cyber-dojos, together with a few examples of code/tests typically submitted, a few dashboard patterns, and wrapped up linking testing to Le Chatelier's Law and some of my favourite Systems Thinking quotes from Bradford Keeney.

Atlantec - tdd lessons from Jon Jagger

management 3.0

is an excellent book by Jurgen Appelo, subtitled Leading agile developers, Developing agile leaders (isbn 978-0-321-71247-9). As usual I'm going to quote from a few pages:

The hierarchy is needed for authorization; the network is needed for communication.

Big species consume more and breed slower.

The Red Queen's Race is an evolutionary hypothesis describing that a complex system needs continuous improvement to simply maintain its current fitness, relative to the systems it is co-evolving with. Some scientists claim that the Red Queen's Race, or the principle of co-evolving species, is an even more important driver of evolution that any other kind of environmental change.

We can consider the internal structure of each system to be a code for the environment and the other species that it is evolving with.

There is no accurate (or rather, perfect) representation of a system which is simpler than the system itself.

We can figure out why the human heart fails (reductionism) but we can never create a heart that won't fail (constructionism).

Managers must learn that they are "in charge" but not "in control".

Recent research has shown that the copying of ideas is the most successful of all strategies.

Uncertainty results in a bias towards self-interest.

Feedback is only feedback when there is a purpose behind it.

Research shows that self-discipline is twice as important as IQ for final grades of students. Effort matters more than talent.

Focus on delivering value.

We need continuous business improvement.

kanban - some quotes

Quality Software Management: Vol 4. Anticipating Change

Taiichi Ohno's Workplace Management

Implementing Lean Software Development

Toyota Production System

Taiichi Ohno's Workplace Management

The Principles of Product Development Flow

How to use conscious purpose without wrecking everything

The Systems Bible

The Psychology of Computer Programming

The Mythical Man Month

Agile Development in the Large

Surfing the Edge of Chaos

XP values - some quotes

The Systems Bible

Management of the Absurd

The Conquest of Happiness

Mastery

The Aesthetics of Change

How to use conscious purpose without wrecking everything

The Agile Manifesto

The Systems Bible

fun with feedback frequency

I'm currently reading Brain of the Firm, by Stafford Beer. On page 36 he writes:

The outcome is startling ... ... the total system is dominated, not by the forward network, but by the feedback network ... The output signals will be of greater 'purity' than we had any right to expect.

The word feedback caught my eye.
Feedback is a key principle of complex adaptive systems.
Feedback is also one of the 4 values of eXtreme Programming.
Feedback also gets several mentions in the official Scrum Guide.
So I've been playing around with Feller's walk (named after William Feller) some more...

Feller's Walk

Each Feller's walk is 1000 steps long, and at each step I flip a fair coin.
As I walk I keep a running total (starting at zero):

• adding one each time I flip a head
• subtracting one each time I flip a tail

What will the total look like as the walk progresses?
Here's the plot of the step (x-axis) against the total (y-axis) during one simulated walk.

It starts at a total of zero on the far left and wanders along, edging upwards when a head is thrown, edging downwards when a tail is thrown, and ending at about -26 indicating that overall there were 487 heads and 513 tails (487-513=-26, 487+513==1000).

Apparently, most people's intuition is that the total will hover around zero.
But it doesn't.
You cannot rely on randomness to correct the problems that randomness creates.
Without constraints variance will accumulate.
If the total happens to be +24 the coin isn't going to throw more tails for a while to try to balance things up.
Without feedback the coin has no memory.

To help see this I simulated 5000 walks and plotted the frequency of the total (y-axis) against the total (x-axis) at various points along the walks:

• after 10 steps in gold
• after 100 steps in blue
• after 1000 steps in red
• I chop the x-axis to +- 2 standard deviations

step	freq[0]	max abs(total)	std.dev
10	1204	-10	3.19
100	405	36	10.15
1000	121	140	31.71

Over all the walks, at the 10th step:

• the total was zero 1204 times (5 heads, 5 tails, 5-5=0, 5+5=10)
• the total farthest from zero was -10 (0 heads, 10 tails, 0-10=-10, 0+10=10)
• the standard deviation of the total was 3.19

Over all the walks, at the 100th step:

• the total was zero 405 times (50 heads, 50 tails, 50-50=0, 50+50=100)
• the total farthest from zero was 36 (68 heads, 32 tails, 68-32=36, 68+32=100)
• the standard deviation of the total was 10.15

Over all the walks, at the 1000th step:

• the total was zero 121 times (500 heads, 500 tails, 500-500=0, 500+500=1000)
• the total farthest from zero was 140 (570 heads, 430 tails, 570-430=140, 570+430=1000)
• the standard deviation of the total was 31.71

The further along the walk I progress, the less likely my total is to be zero.
Without constraints variance will accumulate.

Once again, with feedback

Every Nth step, instead of flipping the coin, I look at the total and:

• if the total is negative (more tails than heads) I pretend I've flipped a head, and add one to the total.
• if the total is positive (more heads than tails) I pretend I've flipped a tail, and subtract one from the total.

This feedback increases the likelihood of the total staying nearer to zero.
The smaller the value of N, the greater the effect.

Estimating feedback effectiveness

Using the simulation I can measure how good (or bad) people's estimates are of how effective feedback is. For example, I can:

• run the simulation with some feedback (N==10 say) and display the results
• gather estimates with no feedback (N==never) of, eg
  • freq[0], or
  • max abs(total), or
  • std.dev, etc
• run the simulation with no feedback and see how the actual results compare.

Or

• run the simulation with no feedback and display the results
• gather estimates of the least feedback needed to, eg
  • triple freq[0], or
  • quadruple max abs(total), or
  • half std.dev, etc
• run the simulation with various amounts of feedback and see how the actual results compare.

I've put the simulation source up on https://github.com/JonJagger/Fellers-1000-coin-tosses.
The simulation runs directly from this URL https://rawgithub.com/JonJagger/Fellers-1000-coin-tosses/master/fellers.html so you can try out various values of N if you want to before reading on...

A little feedback goes a long way

Here's 5000 simulations of a 1000 step walk with N==25.
That means, that every 25th step instead of flipping the coin, the simulation nudges the total towards zero as described above.

step	freq[0]	max abs(total)	std.dev
10	1379	-10	2.97
100	553	32	8.04
1000	387	84	15.18

The effectiveness of one feedback nudge every 25 steps amazes me.

• freq[0] tripled from 121 to 387
• max abs(total) shrank from 140 to 84
• std.dev halved from 31.71 to 15.18

Startling! Just as Stafford Beer said.
Let's hear it for feedback!

patterns of connection

When I read a good book I highlight passages that catch my attention. I copy a few of the highlights into a book-snippet.

This photo is of page 75 of my battered copy of The Secrets of Consulting. The yellow highlights are from the first time I read the book, the pink ones from the second time, the blue ones the fourth time. At the bottom right is one sentence outlined in pen and marked with an eight. That tells me I marked that sentence on my eighth re-read. (I've run out of new colours.)

I find it better to re-read a really good book 10 times rather than read 10 average books once each. It's the really good books that provide new insights each time I re-read them. Marking highlights in this way allows me to go back in time. What topics caught my attention in early readings? What topics in later readings? I can explore the differences. Of course, part of that newness is that I'm a different person each time I re-read. I'm older. A sentence triggers a new thought based an experience I've had since my last read. Also, I remember more of the book each time. For example I can see on my seventh re-read I marked this

The toughest problems don't come in neatly labeled packages. Or they come in packages with the wrong labels.

and I underlined the words labeled and labels because I'd consciously connected them to The Label Law (on page 64).

The name of the thing is not the thing.

Underneath that I can see I've written "The Dread Pirate Roberts". That's a connection to a scene from one of my favourite films, The Princess Bride. Westley is in the fire swamp explaining to Princess Buttercup how he has become the Dread Pirate Roberts...

Westley: I, as you know, am Roberts.

Buttercup: But how is that possible, since he's been marauding twenty years and you only left me five years ago?

Westley: I myself am often surprised at life's little quirks...

Westley: Well, Roberts had grown so rich, he wanted to retire. So he took me to his cabin and told me his secret. "I am not the Dread Pirate Roberts," he said. "My name is Ryan. I inherited the ship from the previous Dread Pirate Roberts, just as you will inherit it from me. The man I inherited it from was not the real Dread Pirate Roberts, either. His name was Cummerbund. The real Roberts has been retired fifteen years and living like a king in Patagonia." Then he explained the name was the important thing for inspiring the necessary fear. You see, no one would surrender to the Dread Pirate Westely.

John Gall (who was born in 1925), recently gave a fabulous talk called how to use conscious purpose without wrecking everything. He said:

As the years go by, the brain begins to put the dots together, to make conscious links between one experience and another, between one historical fact and another. A person begins to experience one’s entire life history as an integrated narrative.

This integrating capacity of the human brain is perhaps its most marvelous achievement. And you have to be old—usually fifty or sixty years old—to reach that point where it dawns on your conscious mind that that’s what’s going on. Unless you are already in your coffin, your mind is always a work in progress, an ongoing process of continual growth and greater differentiation, richer and more far-reaching correlations.

He chatted about how much his mind had changed during the first 40 years of his life compared to the most recent 40 years of his life. He said the latter change was far greater.
Isn't that amazing. Fantastic.
I'm looking forward to getting older!
I'm looking forward to seeing more and more patterns of connection.

feedback

Back to quotes table-of-contents

From The Secrets of Consulting

People can take any amount of water from any stream to use for any purpose desired. People must return an equal amount of water upstream from the point from which they took it.

From The Psychology of Computer Programming

It is a well-known psychological principle that in order to maximize the rate of learning, the subject must be fed back information on how well or poorly he is doing.

From An Ecology of Mind

A man walking is never in balance, but always correcting for imbalance.

From Leverage Points

Missing feedback is one of the most common causes of system malfunction.

From How to Use Conscious Purpose Without Wrecking Everything

Ignoring feedback merely means that the system will eventually experience a massive unpleasant surprise rather than a small unpleasant surprise.

The amount of feedback that is built into living organisms differs by many orders of magnitude from the amount that we build into manmade systems.

Flexibility means the willingness to act in response to the feedback message by actually changing how the system works.

From The Principles of Product Development Flow

The speed of feedback is at least two orders of magnitude more important to product developers than manufacturers...

The human effect of fast feedback loops are regenerative. Fast feedback gives people a sense of control; they use it, see results, and this further reinforces their sense of control.

Fast local feedback loops prevent the accumulation of variance.

From Quality Software Management. Vol 1. Systems Thinking

The feedback model says you can't successfully control anything for very long without information.

From Quality Software Management. Vol 2. First-Order Measurement

Software development is not primarily a manufacturing operation for we (ideally) never develop the same software twice. This uniqueness of product means that Deming's "statistical signal" - though necessary - is not sufficient for feedback control, because there often isn't enough repetition - enough stability - to generate meaningful statistics.

From Quality Software Management. Vol 3. Congruent Action

Information about past behaviour, delivered in the present, which may or may not influence future behaviour.

From Quality Software Management. Vol 4. Anticipating Change

In a feedback control system it's only our perception that determines which is controller and which is controllee.

From What Did You Say?

In other words, it's not so much the feedback that counts, but the struggle to get it - not the feedback, but the feeding-back.

We structure our world so we will not receive feedback that threatens our view.

We don't even wait to ignore feedback, but actively take steps to prevent such feedback from ever happening in the first place.

Don't concentrate on giving feedback; concentrate on being congruent - responding to the other person, to yourself, and to the here-and-now situation...

From Management 3.0

Feedback is only feedback when there is a purpose behind it.

From Talent is Overrated

Practicing without feedback is like bowling through a curtain that hangs down to knee level. You can work on technique all you like, but if you can't see the effects, two things will happen: You won't get any better, and you'll stop caring.

Feedback? At most companies this is a travesty, consisting of an annual performance review dreaded by the person delivering it and the one receiving it. Even if it's well done, it cannot be effective. Telling someone what he did well or poorly on a task he completed eleven months ago is just not helpful.

From Agile Development in the Large

Quick feedback should be the first thing you introduce.

From The Dance of Life

All societies depend for the stability on feedback from the people. Depersonalization reduces feedback to a minimum, contributing to instability and lowering the overall level of congruence in the society.

From Understanding the Professional Programmer

Many programmers… work in environments in which they receive essentially no real feedback embodying the consequences of what they do. Lacking no real feedback, they lack the motivation to attempt changes, and they also lack the information needed to make the correct changes.

From The Systems Bible

Just calling it "feedback" doesn't mean that it has actually fed back. To speak precisely: It hasn't fed back until the system changes course. Up until that point it's merely sensory input.

From The Aesthetics of Change

All simple and complex regulation as well as learning involve feedback. Contexts of learning and change are therefore principally concerned with altering or establishing feedback.

From Surfing the Edge of Chaos

Feedback is the means by which a system talks to itself.

From The Fifth Discipline

Virtually all feedback processes have some form of delay.

Understanding the professional programmer

is an excellent book by Jerry Weinberg (isbn 0-932633-09-9) (I've blogged a snippet review of it before.) As usual I'm going to quote from a few pages:

In the past, we depended on meetings because little was written down.

There are very few ways to measure the quality of a programmer's work unless you are a competent programmer yourself.

How do I work on those aspects of my own personality and problem-solving approach that are so personal I can't even see them, even though they may be the most important factor in my effectiveness as a programmer?

The next generation will come when we outgrow our adolescent fascination with toys and develop an adult interest in people.

I believe the first manager failed because she thought that to manage change you must interact directly with the employee.

If you want people to change what they're doing, make sure they are fed back the consequences of what they're doing.

90 percent of all illness cures itself - with absolutely no intervention from the doctor.

It's sometimes hard to know when someone is listening - rather than merely waiting to seize control of the conversation. One way everyone knew Mack wasn't listening was by noticing how seldom he allowed other people to finish what they were saying.

The secret to all good writing is re-writing.

Our tests have shown that certain implanted errors take fifteen minutes for one person to find, fifteen hours for another, fifteen seconds for a third. A few more people can't find the error no matter how long they search. This kind of variation hardly forms the basis for estimating.

The situation is hopeless but not serious.

Rules are not made to be broken, but neither are they made to be not broken. Rules are made so that the organization operates more efficiently.

Ackoff's Best

Ackoff's Best, by Russell Ackoff is an excellent book by (isbn 978-0-471-31634-3). As usual I'm going to quote from a few pages:

Analysis looks into things; synthesis looks out of things … Analysis yields knowledge; synthesis yields understanding … The former enables us to describe; the latter, to explain … In analytic thinking, the thing to be explained is treated as a whole to be taken apart. In synthetic thinking the thing to be explained is treated as part of a containing whole. The former reduces the focus of the investigator; the latter expands it … Synthesis, or putting things together, is the key to systems thinking just as analysis, or taking them apart, was the key to Machine-Age thinking.

The essential properties of a system taken as a whole derive from the interactions of its parts, not their actions taken separately. Therefore, when a system is taken apart it loses its essential properties. Because of this - and this is the critical point - a system is a whole that cannot be understood by analysis.

Organisms and organisations are systems that usually have purposes of their own. However, the parts of an organism (i.e., hearts, lungs, brain) do not have purposes of their own, but the parts of an organisation do … An organisation with purposeful parts almost inevitably generates internal conflict … An organisation is a system whose major deficiencies arise from the ways its parts interact, not from their actions taken separately.

Automation is fundamentally different from mechanisation. Mechanization has to do with the replacement of muscle; automation with the replacement of mind.

The publicly owned company became a corporation (derived from "corpus", meaning "body") and the chief executive became the "head" of the firm.

Development of individuals and corporations is more a matter of learning than earning.

The most variety-decreasing type of social system is one we call a bureaucracy. A bureaucracy is an organisation whose principal objective is to keep people busy doing nothing. … The problem created by people who are busy doing nothing is that they frequently obstruct others who have real work to do. … Bureaucracies obstruct development. … Because bureaucracies tend to be inefficient and obstruct development they invite and encourage corruption.

If you're going to sin, sin against God, not the bureaucracy. God will forgive you but the bureaucracy won't. [Admiral Hyman G. Rickover]

Wisdom is the ability to see the long-run consequences of current actions, the willingness to sacrifice short-run gains for larger long-run benefits, and the ability to control what is controllable and not to fret over what is not … Even the best planning of which we are capable requires at least as much art as it does science … Planning is not an act but a process …

Today's students are over instructed in what they can better do alone: take things and concepts apart; and they are under instructed in what is very difficult to do alone: put what they have learned together into an understanding of the world and their role in it.

Effectiveness is evaluated efficiency. It is efficiency multiplied by value, efficiency for a valued outcome. Intelligence is the ability to increase efficiency; wisdom is the ability to increase effectiveness … Growth does not require an increase in value; development does.

Separation of the relevant information from the irrelevant is a critical part of problem formation … the reasons for wanting to answer a question determines what is the right answer to it.

A wrong solution to the right problem is generally better than the right solution to the wrong problem, because one usually gets feedback that enables one to correct wrong solutions, but not wrong problems. Wrong problems are perpetuated by right solutions to them.

Even those aspects of an organisation's future that are not affected by what it and others do (e.g. the weather) cannot be forecasted well for more than a short period. As in the case of the weather, however, the need to forecast it can be eliminated by bringing it under control, as we do by building structures within which work can proceed whatever the external weather may be.

Andy and the crusty cobs

My friend Andy works on the railways. He used to work as a master baker at one of the big supermarkets. One of the items he baked was Crusty Cobs.

Clearly customers can only buy Crusty Cobs if there are some Crusty Cobs actually on the shelves. So the supermarket also employed a bakery supervisor to check Crusty Cob availability. (Naturally the supervisor was paid more than Andy. After all he was the supervisor.) Every day, at 4pm, the bakery supervisor arrived, clutching his clipboard, and counted the Crusty Cobs on the shelves; one, two, three, four, five, six, seven... Andy got praised if there was good Crusty Cob availability and chastised if there wasn't.

So Andy adapted. He baked extra batches of Crusty Cobs but waited to put them on the shelves until shortly before 4pm. Crusty Cob availability, as recorded by the supervisor, was very good. Customers wanting Crusty Cobs before 4pm were often disappointed.

A short while later as well as counting the Crusty Cobs on the shelves (always at 4pm), the supermarket also started counting the number of Crusty Cobs actually sold at the tills during the day. Now Andy also got praised if lots of Crusty Cobs were sold.

So Andy adapted. As well as sticking the Crusty Cob labels on the Crusty Cobs, he also printed extra Crusty Cob labels and stuck them on some Soft Rolls (same price). After all, who looks at the labels? So Crusty Cob sales, as recorded at the tills, were always very good. The number of Crusty Cobs actually bought by customers was somewhat less.

Not long after, the supermarket noticed a drop in the sales of Soft Rolls. They asked Andy not to bake so many Soft Rolls.

So Andy adapted. He baked less Soft Rolls, labelled them correctly, and put the extra Crusty Cob labels on the French Sticks. Customers wanting Soft Rolls, at any time, were often disappointed.

Goodhart's Law states:

When a measure becomes a target, it ceases to be a good measure.

Or, more colloquially:

Targets are where measures go to die.

the mind of war

is an excellent book about John Boyd by Grant T. Hammond (isbn 978-1588341785). As usual I'm going to quote from a few pages:

…in order to determine the consistency of any new system we must construct or uncover another system beyond it… One cannot determine the character or nature of a system within itself. Moreover, attempts to do so lead to confusion and disorder.

he was always testing the limits - of airplanes, people, science, the military, and, most especially, bureaucracies.

In dozens of interviews, conducted for this book, the most consistent theme and nearly universal comment was that John Boyd was the essence of an honourable man and incorruptible.

Oral, not written, communication and conviction, not accuracy, still rule in military culture.

Boyd liked putting things together (synthesis) better than analysis (taking things apart)...

He also came to appreciate the routine practice and repetition that was required to become really good at something and to overcome the boredom by focusing on minute improvements.

He observed very carefully.

Boyd could go from 500 knots to stall speed, practically stopping the plane in midair, which would force any aircraft on his tail to overshoot him and thus gain the advantage for Boyd. In another trick, he would stand the F-100 on its tail and slide down the pillar of its own exhaust. Fire would come out of the intake in the nose of the aircraft and the tailpipe simultaneously. A seemingly impossible feat, it was challenged by others. Boyd when to Edwards Air Force Base in California, where NASA had two fully instrumented F-100 aircraft, and demonstrated it and other techniques to a series of nonbelievers. The test pilot at Edwards who challenged him at the time was a fellow by the name of Neil Armstrong.

Boyd had never designed an airplane before, but as he told Colonel Ricci and Gen. Casey Dempsey, "I could fuck up and do better than this."

The rule of thumb in the Air Force is that a plane will gain a pound of weight a day for the life of the aircraft.

High entropy implies a low potential for doing work, a low capacity for taking action or a high degree of confusion or disorder… The tendency is for entropy to increase in a system that is closed or cannot communicate with the external systems or environments.

A natural teacher, he understood that if he told you something, he robbed you of the opportunity to ever truly know it for yourself.

We are never deceived. We only deceive ourselves. [Goethe]

Boyd's dictum: "Ask for my loyalty and I'll give you my honesty. Ask for my honesty and you'll have my loyalty."

dig the trenches before the bombs start falling

If I write code without tests I will end up with low quality code. Worse - I'll discover that having written code without tests I've naturally ended up with a codebase that resists being tested. When this happens the codebase is not being 'malicious'. That's just that way it is. That's exactly the way I grew it. Testability isn't something that appears by magic. If I want a codebase to be testable I have to write tests for it as I go along. So that I find out just how testable it actually is and steer accordingly.

Sun Tzu put it very well in The Art of War when he wrote:

Plan for what is difficult while it is easy, do what is great while it is small.

surfing the edge of chaos

is an excellent book by Richard Pascale, Mark Millemann, and Linda Gioja (isbn 0-609-80883-4). As usual I'm going to quote from a few pages:

As a general rule, adults are much more likely to act their way into a new way of thinking than to think their way into a new way of acting.

Recent study of evolution, both in the natural world and in computer based complex systems, has demonstrated the surprising result that the presence of parasites in a system accelerates evolution dramatically.

The average corporation lives only half as long as the average human being.

The defining feature of a complex adaptive system is its ability to learn.

As the process unfolded, employees repeatedly asked Shapiro to give a more definitive shape to his "vision". He refused to do so. "It will only get in the way," he countered. "People will take it too seriously."

Because we thought our job was to persuade, too often we forgot to listen.

How a system connects with its "external" world is also a key source of that system's health.

Feedback is the means by which a system talks to itself.

Bacteria require three years to circumvent the latest antibiotic; viruses typically outmaneuver vaccines within a year.

Critical to the impact of the [National Training Center] experience is a cadre of 600 instructors, one of whom is assigned to every person with leadership or supervisory responsibilities. These "observers/controllers," as they are called, shadow their counterparts through day after twenty-hour day of intense activity, provide personal coaching, and facilitate a team debriefing called an After Action Review (AAR).

If you awaken with sore muscles, how you feel depends a lot on whether you think you're getting the flu or you believe you are reaping the benefits of a good workout the day before.

local optimization, global pessimization

A well known UK company, let's called them B&O, sells bidgets and odgets. B&O sold me a bidget a few years back. They did a good job. I like the bidget they sold me. It works well. B&O rings me know-and-then to ask if I'm thinking of buying another bidget or my first odget.

Recently B&O rang me and I mentioned I was indeed thinking of buying an odget to go with my bidget. The B&O person on the other end of the phone sounded very pleased and arranged for a B&O salesman to visit me to provide me with an odget quote. On the designated day, at the designated time, the B&O salesman, let's call him Stan, arrived.

Stan didn't know that someone at B&O had spoken to me on the phone and arranged for Stan to provide me an odget quote. So I explained, for a second time, the odget I was thinking of, and where it would go and how big it would need to be. Stan said that he could quote for the odget, but, being honest, there was no point. Since the odget I was after was not a regular odget B&O would simply subcontract the work to a builder, and then charge me the builder's cost plus a fat markup. Stan said I'd be much better off hiring a builder myself.

Stan explained that the people at the B&O office get a cash bonus each time an odget quote is made to a prospective customer. Stan further explained that they got this cash bonus regardless of whether the customer actually bought the odget. Predictably, the people in the B&O office work hard to get quotes out. They send B&O salesman out to any and all jobs regardless of how likely the job is to result in actual work. Stan said if a B&O phone-handler phoned me to ask whether I'd received a quote, he'd very much appreciate it if I said no I hadn't because I'd changed my mind and didn't want an odget.

Top marks to Stan. No marks to B&O.

how to use conscious purpose without wrecking everything

is the title of the truly fantastic talk John Gall gave at Tom Gilb's annual Gilbfest a few weeks ago. You can read the whole thing here. Here's a small selection of the many snippets that spoke to me:

Maximizing efficiency is the error of having a single goal, what William Blake once called “Newton’s sleep.”

Always the more beautiful answer who asks the more difficult question [e.e.cummings]

Evolution always means Co-evolution. The horse eats the grass, the grass grows stronger roots, the horse grows stronger jaws.

What is involved is not simply survival of the fittest, but survival of the fitting-in-est.

The amount of feedback that is built into living organisms differs by many orders of magnitude from the amount that we build into manmade systems.

Flexibility means the willingness to act in response to the feedback message by actually changing how the system works.

There are many Potemkin Villages in operation today, hiding and distracting us from awareness of what’s really going on.

Ignoring feedback merely means that the system will eventually experience a massive unpleasant surprise rather than a small unpleasant surprise.

As Bradford Keeney pointed out, stability is not homeostasis, it’s homeodynamics.

Once you get above that first level, the level of material things and forces, you are dealing with abstractions. In place of physical forces, you have communication—messages, signals. And in place of material things, you have relationships—which are abstractions.

Once we get above the level of physical objects and forces, we are dealing with patterns of interaction, that is, with abstractions.

Abstractions — that is, ideas — don’t die. They can’t be killed. They can’t be exterminated. They just keep coming back, over and over and over. This problem can never be solved if one continues to believe that the so-called "real" world of physical objects and forces is all there is. The Chinese have a word for this. They call it "being stuck in the ten thousand things."

In order to become birds, dinosaurs had to give up being dinosaurs.

If I design a system with no regard for the universe that surrounds it, I will have scanty knowledge of what can impact it.

Dancing with elves

subtitled Parenting as a Perfoming Art, is an excellent book by John Gall (isbn 978-0-9618251-4-0). As usual I'm going to quote from a few pages:

No one can avoid influencing others. The only question is whether we are going to do it knowingly or unknowingly. Our position is that knowledge is better than ignorance.

Command-and-control tries to get 100% compliance - an impossible goal. In the name of discipline, it teaches rigidity.

The mother bird repeats the sequence over and over, with endless patience, until the children learn. You never see a mother bird attack her offspring; you never see her punish her baby for failure to learn the lesson. When the adult animal teaches their offspring, it is done by one method and that is by modelling over and over the desired behaviour.

Talking about your own experiences causes others to access their own similar experiences. I wish I could get across to you how powerful this effect is and how silently it operates.

Words have this incredible power to call up experience.

What a momentous thing you are doing when you speak words to your child or to your spouse or to any other person. You have the power to create their experience, you have the power to shape it, to make it beautiful. You can give them the experience of competence, of comfort, of success.

Somewhere between the first week of life and age forty or fifty, something rather serious happens. We stop using our feedback. We're carefully taught to pay attention to the program inside our head, instead of what's happening in the real world.

When you speak to someone, they split into two pieces. This happens all the time, to everybody. There's a part that wants to go along with what you say, and then there's a part that wants to defend their individuality, they're not going along. There's the part that agrees, and a part that disagrees, simultaneously.

It obviously doesn't make sense to demand impulse control from a little person that doesn't have it.

If you see "stubbornness" then you're naturally going to expect certain things. You're going to act in certain ways, you're going to get an interaction started that assumes this.

What does it mean when you say a person is "just lazy?" or "just stubborn?". It really means that you have tried out some of your repertoire of behavioural interventions in order to elicit a desired piece of behaviour from the other person and you have failed, because your repertoire was too limited.

sliming and refactoring and deliberate duplication

Suppose I'm doing the Print-Diamond kata in Ruby:

Given a letter print a diamond starting with 'A' 
with the supplied letter at the widest point. 
For example: print-diamond 'E' prints
    A
   B B
  C   C
 D     D
E       E
 D     D
  C   C
   B B
    A

I start with a test

def test_diamond_A
  assert_equal ['A'], diamond('A')
end

which I pass using

def diamond(widest)
  ['A']
end

I add another test

def test_diamond_B
  assert_equal [' A',
                'B B',
                ' A'], diamond('B')
end

which I pass using

def diamond(widest)
  if widest == 'A'
    return ['A']
  end
  if widest == 'B'
    return [' A',
            'B B',
            ' A']
  end
end

I add one more test

def test_diamond_C
  assert_equal ['  A',
                ' B B',
                'C   C',
                ' B B',
                '  A'], diamond('C')
end

which I pass using

def diamond(widest)
  if widest == 'A'
    return ['A']
  end
  if widest == 'B'
    return [' A',
            'B B',
            ' A']
  end
  if widest == 'C'
    return ['  A',
            ' B B',
            'C   C',
            ' B B',
            '  A']
  end
end

The tests have already proved valuable:

• I've decided I don't want to actually test printing
• I've chosen the result format - an array of strings
• I've chosen not to embed newlines at the end of the strings
• I've something to refactor against

However, there is no point in carrying on sliming. As the tests get more specific, the code should get more generic. I have three specific tests, but the code is equally specific. I need to generalize the code.

While coding the array of strings for the 'C' case I found myself copying the result for 'B' and modifying that. Specifically, I had to:

• duplicate the 'B B' string
• add a space at the start of the ' A' and 'B B' strings
• add a new middle string 'C C'

This gave me the idea to try a recursive implementation. My first step was to refactor the code to this:

def diamond(widest)
  d = inner_diamond(widest)
  mid = d.length / 2
  d[0..mid-1] + d[mid+1..-1]
end

def inner_diamond(widest)
  if widest == 'A'
    return ['A',
            'A']
  end
  if widest == 'B'
    return [' A',
            'B B',
            'B B',
            ' A']
  end
  if widest == 'C'
    return ['  A',
            ' B B',
            'C   C',
            'C   C',
            ' B B',
            '  A']
  end
end

This looks a promising step towards a recursive solution - to make the implementation of 'C' contain the implementation of 'B' and then add strings only for 'C'. So, remembering what I had to do when copying and modifying, I refactored to this:

def inner_diamond(widest)
  if widest == 'A'
    return ['A',
            'A']
  end
  if widest == 'B'
    return [' A',
            'B B',
            'B B',
            ' A']
  end
  if widest == 'C'
    b = inner_diamond('B')
    upper,lower = split(b.map{ |s| ' ' + s })
    c = widest + '   ' + widest
    return upper + [c,c] + lower
  end
end

def split(array)
  mid = array.length / 2
  [ array[0..mid-1], array[mid..-1] ]
end

From here I verified the recursive solution works for 'B' as well:

def inner_diamond(widest)
  if widest == 'A'
    return ['A',
            'A']
  end
  if widest == 'B'
    a = inner_diamond('A')
    upper,lower = split(a.map{ |s| ' ' + s })
    b = widest + ' ' + widest
    return upper + [b,b] + lower
  end
  if widest == 'C'
    b = inner_diamond('B')
    upper,lower = split(b.map{ |s| ' ' + s })
    c = widest + '   ' + widest
    return upper + [c,c] + lower
  end
end

Now I worked on generalizing the use of the hard-coded argument to inner_diamond() and the hard-coded number of spaces:

def inner_diamond(widest)
  if widest == 'A'
    return ['A','A']
  end
  if widest == 'B'
    a = inner_diamond(previous(widest))
    upper,lower = split(a.map{ |s| ' ' + s })
    n = (widest.ord - 'A'.ord) * 2 - 1
    b = widest + (' ' * n) + widest
    return upper + [b,b] + lower
  end
  if widest == 'C'
    b = inner_diamond(previous(widest))
    upper,lower = split(b.map{ |s| ' ' + s })
    n = (widest.ord - 'A'.ord) * 2 - 1
    c = widest + (' ' * n) + widest
    return upper + [c,c] + lower
  end
end

def previous(letter)
  (letter.ord - 1).chr
end

Now I collapsed the duplicated specific code to its more generic form:

def inner_diamond(widest)
  if widest == 'A'
    return ['A','A']
  else
    a = inner_diamond(previous(widest))
    upper,lower = split(a.map{ |s| ' ' + s })
    n = (widest.ord - 'A'.ord) * 2 - 1
    b = widest + (' ' * n) + widest
    return upper + [b,b] + lower
  end
end

Finally some renaming:

def inner_diamond(widest)
  if widest == 'A'
    return ['A','A']
  else
    inner = inner_diamond(previous(widest))
    upper,lower = split(inner.map{ |s| ' ' + s })
    n = (widest.ord - 'A'.ord) * 2 - 1
    middle = widest + (' ' * n) + widest
    return upper + [middle,middle] + lower
  end
end

To summarise:

• When sliming I try to think ahead and choose tests which allow me to unslime the slime.
• If I have slimed 3 times, my next step should be to unslime rather than adding a 4th gob of slime.
• My first unsliming step is often deliberate duplication, done in a way that allows me to collapse the duplication.

The principles of product development flow

is an excellent book by Donald Reinersten (isbn 978-1-935401-00-1). As usual I'm going to quote from a few pages:

Operating a product development process near full utilisation is an economic disaster.

When we emphasise flow, we focus on queues rather than timelines.

Almost any specialist can become a queue.

We grow queues much faster than we can shrink them.

When queues are large, it is very hard to create urgency.

Queues amplify variability. Moving from 75 to 95% utilisation increases variability by 25 times.

Sequential phase-gate processes have inherently large batch transfers.

Large batches encourage even larger batches.

Reducing batch size is usually the single most effective way to reduce queues.

Companies inevitably feel they can computerise this whiteboard, however, they almost always create a more elegant but less useful system.

The speed of feedback is at least two orders of magnitude more important to product developers than manufacturers.

The human effect of fast feedback loops are regenerative. Fast feedback gives people a sense of control; they use it, see results, and this further reinforces their sense of control.

Homeostasis is the tendency of a system to maintain its current state.

In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.

Opportunities get smaller with time, and obstacles get larger.

The scarcest resource is always time.

To align behaviours reward people for the work of others.

It has been said that one barbarian could defeat one Roman soldier in combat, but that 1,000 Roman soldiers could always defeat 1,000 barbarians.

The Marines, and all other elite organisations, maintain continuity in their organisational units.