the reason I jump

is an excellent book by Naoki Higashida, subtitled One boy's voice from the silence of autism (isbn 978-1-4447-7677-5). As usual I'm going to quote from a few pages:

The Reason I Jump unwittingly discredits the doomiest idea of received wisdom about autism - that people with autism are anti-social loners who lack empathy with others. (Foreword)

I very quickly forget what it is I've just heard. Inside my head there really isn't such a big difference between what I was told just now, and what I heard a long, long time ago.

What makes us smile from the inside is seeing something beautiful, or a memory that makes us laugh. This generally happens when there's nobody watching us. And at night, on our own, we might burst out laughing underneath the duvet.

When I see I've made a mistake, my mind shuts down. However tiny the mistake, for me, it's a massive deal. Once I've made a mistake, the fact of it starts rushing towards me like a tsunami. And then, like trees or houses being destroyed by the tsunami, I get destroyed by the shock.

There are times when I can't act, even though I really, badly want to. This is when my body is beyond my control.

When I'm jumping, I can feel my body parts really well... and that makes me feel so, so good. By jumping up and down, it's as if I'm shaking loose the ropes that are tying up my body. When I jump I feel lighter.

It's not quite that the noises grate on our nerves. It's more to do with a fear that if we keep listening, we'll lose all sense of where we are.

My guess is that the despair we're feeling has nowhere to go and fills up our entire bodies, makes our senses more and more confused.

When you see and object, it seems that you see it as an entire thing first, and only afterwards do its details follow on. But for people with autism, the details jump straight out at us first of all, and then only gradually, detail by detail, does the whole image sort of float up into focus.

Numbers are fixed, unchanging things. That simplicity, that clearness, it's so comforting to us. Invisible things like human relationships and ambiguous expressions, however, these are difficult for us people with autism to get our heads around.

I understand that any plan is only a plan, and is never definite, but I just cannot take it when a fixed arrangement doesn't proceed as per the visual schedule. Visual schedules create such a strong impression on us that if a change occurs, we get flustered and panicky.

We can put up with our own hardships okay, but the thought that our lives are the source of other people's unhappiness, that's plain unbearable.

some cyber-dojo measurements

cyber-dojo has hosted about 13,000 practice sessions so far. I've written a short ruby script to extract some measurements from a sample of 500 sessions. I was looking at transitions between red, amber, and green traffic-lights:

• red means one or more tests failed
• amber means the tests did not run (eg syntax error)
• green means the tests ran and all passed

The first column is average number of lines added/deleted.
The second column is colour → colour transition.
The third column is sample size.

3.94	amber → green	447
4.65	amber → red	379
4.67	amber → amber	1462
5.39	red → green	607
6.01	red → red	604
7.52	green → red	420
13.65	green → amber	436
17.67	red → amber	432
22.18	green → green	598

Here's how I interpret the results:

• If you're at red or green and you make a small change (5.39,6.01,7.52) you're likely to stay at red or green.
• If you're at red or green and you make a large change (13.65,17.67) you're likely to transition to amber.
• There is a big spike in the number of amber → amber transitions (1462). I speculate that long sequences of these transitions are occuring after a large 13.65 green → amber or 17.67 red → amber transition.
• I think the green → green value of 22.18 is larger than it should be because it's including plain file renames.

kanban push-me pull-you

The video of the kanban push-me pull-you presentation I gave at David Anderson's Lean Kanban UK conference is now up on youtube. Here's the slide-deck too.

software blending

Here's a story from the book Dr Deming by Rafael Aguayo.

In the early 1950s, American coffee roasters faced a dilemma. The price of coffee beans had risen dramatically, and they were faced with two distasteful choices: either absorb the increased price, partially or totally, hurting profitability; or pass the cost on to their customers and risk losing market share or having customers switch to other beverages.

They came up with an innovative alternative. The coffee roasters' business consists of buying, ageing, roasting, and blending coffee beans to achieve the desired state and smell. Coffee beans, like all agricultural commodities, are highly variable. Two beans can be quite distinct. Even beans picked at the same time from the same tree can be different. A bean picked from the top of the tree, which receives more sunshine, tastes different than a bean from the bottom of the tree.

Blending is a critical part of the process. The leading roaster of the time tried experimenting with different formulations. It found that gradually changing the formulation, substituting lower quality beans, was unnoticeable to the customer. It begins to slowly change the blend. Every two weeks a few more of the less expensive beans were substituted for the heartier, more expensive ones. Most consumers couldn't notice the difference in coffees bought two weeks apart. But if they had tasted, side by side, two batches made six weeks apart, they would have noticed a slight difference.

In effect, the roaster started training customers to accept an inferior blend of coffee. The other roasters noticed what was going on and responded in kind to avoid losing market share. In a few years the American consumer's standards for a decent cup of coffee were radically altered. The managers did their jobs and enjoyed their bonuses. At the time this response was viewed as a triumph of ingenuity. But a funny thing began to happen. Per capita consumption of coffee began a slow but steady decline. The business stopped growing. The roaster that started it all began to experience profitability problems. It is now part of a huge conglomerate and is still experiencing problems in its coffee business. Consumers have discovered gourmet coffees. But ironically, the coffee drunk by Americans during the 1940s was on a par with what we now call gourmet coffees.

Isn't it great! It reminds me of the Fast Food Fallacy from Jerry Weinberg's The Secrets of Computing:

No difference plus no difference plus no difference plus ... eventually equals a clear difference

I emailed the story to Jerry and he replied:

Great story. Even though I've never had a cup of coffee in my life, I can appreciate the dynamic. Indeed, the same dynamic has occurred over and over. I've written about white bread's deterioration - and now we have "gourmet" breads.

And, I suspect, the same thing is now happening in software - gradually lowering the quality of apps, as expectations lower. Then we will have software selling on the basis of freedom from those annoying bugs. Same thing in security, I think.

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

visibility

Back to quotes table-of-contents

From The Secrets of Consulting

Most of what a plant is doing is out of sight.

From The Toyota Way

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

From Quality Software Management. Vol 4. Anticipating Change

Without action things will only get less visible over time.

A measurement system helps makes the software product visible.

Software is invisible only when we have not developed the correct engineering measurements. A hundred years ago electricity was considered invisible. We only knew of its existence when it shocked us.

From Leverage Points

They [feedback loops] may not be very visible. But their presence is critical to the long-term welfare of the system. One of the big mistakes we make is to strip away these "emergency" response mechanisms because they aren't used often and they appear to be costly.

From Situated learning - Legitimate peripheral participation

A window's invisibility is what makes it a window, that is, an object through which the outside world becomes visible.

From Implementing Lean Software Development

The behaviours that ranking systems encourage are competition, hiding information so as to look good, and hiding problems so as not to look bad.

From Toyota production system

The vicious cycle of waste generating waste hides everywhere in production.

From The Silent Language

Culture hides much more than it reveals, and strangely enough what it hides, it hides most effectively from its own participants.

From Brain Rules

Vision is by far our most dominant sense, taking up half of our brain's resources.

From Mending a bike puncture

Air, like software, is invisible. To get the hole to reveal itself I switched to a different medium, from air to water.

From What Did You Say?

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

From General Principles of Systems Design

Regulation is invisible - when it works.

From the DevOps Handbook

The principle of small batch sizes also applies to code reviews.

an ecology of mind

is an excellent dvd, by Nora Bateson, about her father, Gregory Bateson, who wrote An Ecology of Mind. As usual here's are some selected quotes:

Without context, words and actions have no meaning at all. This is true of all communication... [Gregory Bateson]

A role is a half-arsed relationship. It's one end of a relationship. You cannot study only one end of a relationship and make any sense. What you will make is disaster. [Gregory Bateson]

I've been bothered a little bit the past few days by people who say, "What do you mean 'ecology of mind'". And approximately what I mean is that the various sorts of 'stuff' that goes on in ones heads and in ones behaviour, and dealing with other people and walking up and down mountains, and getting sick and getting well and all that. That all that stuff interlocks, and in fact constitutes a network, and you've got the sort of complicated, living, partly struggling, partly co-operating, tangle, that you find on the side of any of these mountains with the trees and various plant and animals that live there. In fact an ecology. [Gregory Bateson]

The division of things into parts tends to be a device of convenience, and that's all. [Gregory Bateson]

Wise men see outlines and therefore they draw them. [William Blake]
Madmen see outlines and therefore they draw them. [William Blake]
If a fool should persist in his folly, he would become wise [William Blake]

The difference that makes a difference is a way in which to define something in terms of its relationships, using contrast and context, instead of isolating it with a name. [Nora Bateson]

Krishnamurti said something like "You might think you're thinking your own thoughts. You're not. You're thinking your culture's thoughts." [Nora Bateson]

I guess I've been reading too much Alice. [Gregory Bateson]

The double-bind is a creative imperative. Its the moment when, because this doesn't work and that doesn't work, something else is going to have to be improvised. A creative impulse is necessary at that moment, to get out of the situation, to take it up a level. [Nora Bateson]

The combination of theme with variation immediately points you to something behind it. A formative principle. [Terrence Deacon]

He was often accused of talking in riddles and never coming to the point. The question he posed "What is the pattern that connects?" was never meant to be answered, because the patterns are changing. It was the act of questioning that he was pushing for. Knowing that the eyes behind that curiosity will be the most apt to give the patterns of connection room to wiggle as they perpetually self correct. And to see the beauty in that process. [Nora Bateson]

When you see process you see constant change. That's why Gregory was constantly quoting Heraclitus "no man can step into the same river twice". Because it's flowing. [Mary Bateson]

Only by the creation of change can I perceive something. [Gregory Bateson]

A man walking is never in balance, but always correcting for imbalance. [Gregory Bateson]

He asked the question "What is there about our way of perceiving that makes us not see the delicate interdependencies in an ecological system, that give it its integrity." We don't see them, and therefore we break them. [Mary Bateson]

Any kind of aesthetic response is a response to relationships. [Mary Bateson]

I hope it may have done something to set you free from thinking in material and logical terms, when you are, in fact, trying to think about living things. [Gregory Bateson]

the right stuff

is an excellent book by Tom Wolfe (isbn 978-0-099-47937-6). A marvelous tale of courage. As usual I'm going to quote from a few pages:

In the military they always said "flight test" and not "test flying".

Once the theorem and the corollary was understood, the Navy's statistics about one in every four Navy aviators dying meant nothing. The figures were averages, and averages applied to those with the average stuff.

What people were seeing on television were, in fact, ordinary test events. Blown engines were par for the course in testing aircraft prototypes and were inevitable in testing an entirely new propulsion system, such as jet or rocket engines.

Conrad stares at the piece of [blank] paper and then looks up at the man and says in a wary tone, as if he fears a trick: "But it's upside down."

This obsession with active control, it was argued, would only tend to cause problems on Mercury flights. What was required was a man whose main talent was for doing nothing under stress.

The boys' response, however, had not been resignation or anything close to it. No, the engineers now looked on, eyebrows arched, as the guinea pigs set about altering the experiment.

The esprit throughout NASA was tremendous... Bureaucratic lines no longer meant anything. Anyone in Project Mercury could immediately get to see anybody else about any problem that came up.

They had barely moved the first stick of furniture in when the tour buses started arriving, plus the freelance tourists in cars. ... Sometimes people would get out and grab a handful of grass from your lawn. They'd get back on the bus with their miserable little green sprouts sticking out of their fingers. They believed in magic.

Herein the world was divided into those who had it and those who did not.

systems thinking slide deck

Here are the slides for the talk on Systems Thinking that Niklas Bjornerstedt and I did in the Scotsman pub in Oslo yesterday. The point about "Your wife is very beautiful" is that it is very easy to read that in a static sense. To get a sense of reading it in a more dynamic (relative) sense, imagine if someone replies "compared to who?!"

The books mentioned in the talk are:

• The Systems Bible by John Gall
• The Secrets of Consulting by Jerry Weinberg
• Aesthetics of Change by Bradford Keeney
• Steps to an Ecology of Mind by Gregory Bateson
• The Principles of Production Development Flow by Donald Reinersten
• Slack by Tom DeMarco
• Quality Software Management: Volume 1 - Systems Thinking by Jerry Weinberg
• Freedom from Command and Control by John Seddon

The Law of Unintended Consequences slide has three images for these three stories:

• Andy and the Crusty Cobs
• The Cobra Effect
• Dolphins are Deep Thinkers

the (de)composition fallacy

You've probably heard the saying "the whole is greater than the sum of the parts". You can think about this law in various ways. For example, if you remove the brain from a man you no longer have a man minus a brain. You have two dead things. A brain is more than just a "part" of a man. A part has relationships to a whole that contribute to the essential wholeness of the whole.

Another way is at a much simpler level - where all the parts are of the same type aggregating together over time. Time patterns them. Human beings are pretty poor at seeing effects over time. We tend to think things are more permanent than they are. We think that the way things are now is how they've always been and how they'll continue to be. I recall showing my children some old Victorian pennies and telling them that's what pennies used to look like. They didn't believe me! Before street lighting it was apparently very common in England to have two sleeps a day. The short one after a midday meal was called the "small sleep". The time we eat our main meal has changed. Eating several courses at a meal is a relatively recent phenomenon. The cutlery we eat with has changed. And what we wear. Before the 17th century your left and right shoe (if you had shoes at all) were the same and were called "straights".

But things do change, and this matters because

Things that don't matter in isolation often matter in composition.

Suppose you compile some code and you get a few warnings. Do these warnings matter? You might think not, since there are only a few, but they do. Tomorrow you'll be writing some more code, and the day after that some more too, and so will your colleagues. After six months those few warnings have turned into 3000 warnings. That's the composition fallacy.

3000 warnings is a big problem for at least two reasons. But the two reasons I'm thinking of are really the same reason. Let me explain.

The first reason is that if you've got 3000 warnings then any new warnings aren't even noticed in the comparative vastness of the existing 3000. You've become completely desensitized to warnings. The number of warnings inexorably grows but no one notices - you've just got "a lot of warnings" that is always "a lot of warnings".

The second reason is the same reason but in reverse.

Suppose you see what you couldn't see before - that a lot of warnings is a composition problem - and you try to do something about it. You've now got to work hard learning how to do something you don't know how to do - namely how to write code without warnings. That takes effort. And what do you get for all your effort? Almost nothing it seems! The number of warnings goes down a tiny bit but there are so many warnings you've hardly made any difference at all. A lot of warnings remains a lot of warnings.

One thing you can do in this situation is to stop reporting the total number of warnings and switch to reporting only the number of warnings either added or removed. This is an example of switching from a static measure (the number of warnings is now 2981) to a more dynamic measure (in the last 24 hours the number of warnings has gone down by 19).

kanban push-me-pull-you

I've been thinking some more about kanban and visualization. A while ago I blogged about my security-scan kanban idea of introducing proper physical kanban onto the board. Instead of writing a work-in-progress limit of 5 at the top of a column you introduce 5 physical "empty-tray" kanbans. Different columns use different coloured kanban. For example, here's a very simple kanban board with a Wibbling limit of 4 yellow trays and a Fubaring limit of 5 red trays. The stories are in blue and must always be in a tray.

I mentioned how this allows genuine pulling. For example, the Fubarers can signal they're ready to pull a story from the Wibblers by moving an empty red kanban tray into the Wibbling column.

I said that the Wibblers could simply move a done blue story from its yellow kanban into an empty red kanban. Something about that bothered me and I think I now know what it is. Once again it's about visualization. What bothers me is that there is no representation of whether a blue story is done until it's moved into an empty kanban. There is no visual display of whether a blue story actually is "in-progress" and being worked on, or whether its "in-queue" and waiting for an empty red kanban. That feels wrong.

More recently, I blogged about about the common pattern of splitting each column; one for ongoing, one for done, like this. Something about the done column didn't feel quite right either.

So here's what I'm thinking. As well as moving empty-kanbans upstream to signal a pull, you can also move full-kanbans downstream to signal a push. For example, when a Wibbler finishes a blue story they don't leave it in their Wibbling column, waiting for a red kanban pull signal, they move it, still in its yellow kanban, into the Fubaring column, like this:

Ideally, the departing full-yellow-kanban will be just-in-time to meet an arriving empty-red-kanban between the columns...

...and the blue-story will flow from the full-yellow-kanban into the empty-red-kanban:

On the other hand, if the Wibblers are working much faster than the Fubarers then the Fubarer's column will fill up with full-kanban push-requests:

As the Fubarer's column fills up with full-kanban push-requests from upstream it's likely it will also be filling up with empty-kanbans pull-requests from downstream (in green say):

Push-me-pull-you is very visual:

• There's one representation of flow ; thin columns with kanban of one colour only.
• There's a different representation of lack of flow ; fat columns filling up (at the bottleneck) with two or three different coloured kanbans.

Push-me-pull-you points to problems:

• If the yellow Wibblers work faster than the downstream red Fubarers, the Wibbler's full yellow kanban get stuck downstream in the Fubarer's column, inviting the Wibblers to help the Fubarers.
• If the red Fubarers work faster than the upstream yellow Wibblers, the Fubarer's empty red kanban get stuck upstream in the Wibbler's column, inviting the Fubarers to help the Wibblers.

Push-me-pull-you has helped me understand:

• pull does not preclude push; you can have push and pull.
• wip-limits are not limited to pull systems; wip-limits would help in push systems too.

stuka pilot

is an excellent book by Hans Ulrich Rudel (isbn 978-1908476876). As usual I'm going to quote from a few pages:

He tells me that a large scale offensive is in preparation in my sector... approximately three hundred tanks are to be employed in this operation... The number three hundred flabbergasts me... I reply that I find some difficulty in believing it... He says to me, half in earnest, half in jest: "If I didn't know you, for two pins I would have you put under arrest for saying such a thing. But we will soon find out." He goes to the telephone and is connected with the Chief of the General Staff. "You have just given the Fuhrer the figure of three hundred tanks for operation X." "Yes I did." "I want to know the names of the divisions concerned with their present strength in tanks. I have somebody with me who is well acquainted with the position." ... the Chief of the General Staff has the bad luck to begin with the 14th armoured division. He says it has sixty tanks. Goering can hardly contain himself. "My man reports that the 14th has one!" A lengthy silence at the other end of the line. "When did he leave the front?" "Four days ago." Again silence. Then "Forty tanks are still on their way to the front. The rest are in repair shops on the line of communications, but will certainly reach their units by zero day, so that the figures are correct." He has the same answer for the other divisions. The Reichsmarschall slams down the receiver in a rage. "That is how it is!" The Fuhrer is given a totally false picture based on incorrect data and is surprised when operations do not have the success expected... The South Eastern zone with its network of communications is being incessantly blanketed by the enemy's bomber formations. Who knows how many of those forty tanks, for example, will ever reach the front or when? Who can say if the repair shops will get their spare parts in time and if they will be able to complete their repairs within the specified time?

In ministries and departments, however, mistakes are denied on principle.

Another confirmation of the truth of our old Stuka maxim: "Nothing comes off - except what you have practised."

We have long since ceased to develop practice from theory; we do just the opposite.

The fitters have their hands full, for the aircraft have been heavily damaged by flak. The life of such an aeroplane will always be limited.

Little by little I discover all the tricks. Skill is often the result of getting hurt.

I now see that perfectly plainly. We are alone to possess this knowledge; the responsibility is ours.

security scan kanban

There's something about the typical kanban board I see that feels wrong. Let me try to explain. It's to do with what kanban means; what a kanban is. A true kanban is a physical thing used to regulate supply and demand. For example, consider putting your hand-luggage through an airport security scanner. You put your hand-luggage into empty trays. The trays go through the scanner. At the other side you take your hand-luggage out of the trays. The emptied trays go back to the start (often on a separate conveyor belt underneath) for someone else to put their hand-luggage into. Often you're ready to put your hand-luggage through the scanner but you have to wait because there are no empty trays. The number of trays represents the capacity of the system. Each tray is a kanban.

Now let's take a look at a typical kanban board such as the one on the left. It has two columns; one column for the activity of Wibbling which has a work-in-progress (WIP) limit of 5, and one column for the activity of Fubaring which has a work-in-progress limit of 4. There are 3 blue stories being Wibbled and 4 blue stories being Fubar'd.

How is this board supposed to be used? I count the number of blue stories currently being Wibbled - 1,2,3. I look up to the top of the Wibbling column and see its WIP limit is 5. I know 3 is less than 5 so I know there is some spare Wibbling capacity. If I want to know how much I can do the math, 5-3==2. And repeat... I count the number number of blue stories currently being Fubar'd - 1,2,3,4. I look up to the top of the Fubaring column and see its WIP limit is 4. I know 4 is the same as 4 so there is currently no spare Fubaring capacity.

It seems odd to have two columns that look exactly the same when one has spare capacity and the other does not!

My problem is that 5 and 4 are abstractions!
5 is not the same as 5 trays.
5 is just 5.
But 5 trays is [Tray Tray Tray Tray Tray].

What's important about the 5 isn't the 5.
What's important about the 5 is that it represents 5 trays.
What's important about the 5 is the relationship between the 5 and the number of blue stories it limits. The Wibbling blue story WIP limit is abstracted to a 5 but the blue stories are not. I have 1,2,3 blue stories in the Wibbling column but I'm not representing them with a 3, I'm representing them with 1,2,3 actual blue story cards.

Here's the alternative 'scan kanban' I'm thinking of.
I remove the 5 WIP limit from the top of the Wibbling column. Instead I put in 1,2,3,4,5 orange  Tray s.
I remove the 4 WIP limit from the top of the Fubaring column. Instead I put in 1,2,3,4 red  Tray s.

I add the rule that every  Story  must always be in a tray.

Now I can instantly see the Wibbling column has some spare capacity because there are some  Tray s with no  Story  in them. I can count the spare capacity if I want -  1 ,  2 . No math needed. Easy. I can instantly see the Fubaring column has no spare capacity because all the  Tray s contain a  Story .

Now I have a kanban board that actually has kanban on it!
Each tray is a kanban.
Now I can experience pull.

Suppose the workers to the right of the Fubaring column use green  Tray s. They send an empty  Tray  to the Fubaring column to signal they're ready to pull a  Story .

The workers in the Fubaring column move a done  Story  from their  Tray  into the empty  Tray .

The workers to the right of the Fubaring column pull the  Story  in its  Tray  back into their column.

The workers in the Fubaring column now have an empty  Tray .

The workers in the Fubaring column can send their empty  Tray  to the Wibbling column to signal they're ready to pull a  Story .

Thus each  Story  flows left to right while each empty  Tray   Tray   Tray  moves right to left.

Once we have a system under control we can try to improve. For example, we can see what happens when we reduce the WIP limit by 1 in the Wibbling column. We simply remove a  Tray .





Caveat Emptor: I've never seen this style of kanban in actual use. It's just an idea so far. As always, if anyone has any feedback it would be much appreciated.

Update! Here's a follow up blog entry.

Quality Software ManagementVol 4. Anticipating Change

is an excellent book by Jerry Weinberg (isbn 0-932633-32-3). This is the second (or is it third?) snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

Ultimately what helps you most in managing system size is courage and realism.

Without action things will only get less visible over time.

Human systems don't change unless the individuals change, one at a time.

Growth is always non linear.

... the incidence of test failures is directly proportional to the square of the size of the crowd multiplied by the rank of the senior observing official [Augustine's Laws]
The dynamic behind this law is simple: A large crowd of high dignitaries means that the event is planned according to external, not internal, events.

It is easy to look at this diagram and believe that you're seeing a defined process. You're not. What you're seeing is an optical illusion.

"model" is just another name for a guide to anticipating the future.

Cultural changes have a much greater potential impact than process changes because one cultural change - such as driving fear out of the workplace - can affect hundreds of process changes.

Feedback works on continuity. The pieces in the model cannot be too large (or response will be slow), and they must be stable (or response will not be predictable).

Error prone modules are born error prone and stay error prone.

the silent language

is an excellent book by Edward T. Hall (isbn 0-385-05549-8). As usual I'm going to quote from a few pages:

Culture hides much more than it reveals, and strangely enough what it hides, it hides most effectively from its own participants.

Interaction has its basis in the underlying irritability of all living substance.

Culture is saturated with both emotion and intelligence.

Theodosius Dobzhansky, the great human geneticist, once observed that life was the result of neither design nor chance but the dynamic interaction of living substance with itself. He meant that life, in a changing environment, places such strains on the organism to adapt that, if this does not take place constantly, the organism as a species dies out.

Different cultures are analogous to different species in the sense that some of them survive whilst others perish. Some are more adaptive than others. The study of change, therefore, is the study of survival.

An often noted characteristic of culture change is that an idea or a practice will hold on very persistently, apparently resisting all efforts to move it, and then, suddenly, without notice, it will collapse.

The idea of looking at culture as communication has been profitable in that it has raised problems which had not been thought of before and provided solutions which might not otherwise have been possible.

We say, "I'll see you in an hour." The Arab says, "What do you mean, 'in an hour'? Is the hour like a room, that you can go in an out of it?" To him his own system makes sense: "I'll see you before one hour," or "I'll see you after one week." We go out in in the rain. The Arab goes under the rain.

...we all hold an illusion about talking, an illusion that talking is quite untrammeled and spontaneous and merely 'expresses' whatever we wish to have it express. This illusory appearance results from the fact that the obligatory phenomena within apparently free flow of talk are so completely autocratic that the speaker and the listener are bound unconsciously as though in the grip of a law of nature. [Benjamin Whorf, Linguistics as an Exact Science]

Complete lack of congruence occurs when everything is so out of phase that no member of a culture could possibly conceive of himself creating such a mess.

Many artists... are credited with "creating" new patterns. Yet most artists know that what greatness they have lies in being able to make meaningful statements about what is going on around them. They say what others have tried to say but say it more simply, more directly, and more accurately, more incisively and with greater insight.

Talking about them... changes our relation with them. We move into an active and understanding correspondence with those aspects of our existence which are all too frequently taken for granted or which sometimes weigh heavily on us. Talking about them frees us from their restraint.

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.

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.

smell-driven development

After much research by our scientists I can finally report a major advance in software methodology - smell driven development.

Our scientists have perfected a set of software metrics which accurately monitor the health of your software. These metrics are gathered in real time by our patented custom SmellWare servers. Each SmellWare server (prices to be announced shortly) is connected via USB to three glass vials and a sophisticated spray-atomizer.

• When the metrics read by the SmellWare server indicate your software is in a poor state, the atomizer will spray scent from the first glass vial.
• When the metrics indicate a further deterioration, the atomizer will spray scent from the second glass vial.
• When the metrics indicate a really disgusting codebase, the atomizer will spray scent from the third glass vial.

By choosing smells with an increasing tendency to get on the developers' olfactory nerves you can "visualize" the state of your codebase in a way that cannot be ignored!

The genius of this approach is that smell, being the oldest sense, has had the longest to evolve. The olfactory sense is, at the same time, both the most primitive sense and the most sophisticated. Even in humans about 1 in 50 genes is devoted to smell-related protein receptors!

Our odour scientists have studied the four aspects of threshold and tolerance; odour concentration, odour intensity, odour quality, and hedonic tone, and after extensive field testing the first (cheese based) vials are ready.

• Vial 1 (Yellow) is based on Pong-Leveque (Normandy) and is ranked "distinct, strong, and unpleasant" on the Odour Awareness scale.
• Vial 2 (Amber) is based on Epoisses de Pieds (Southern Italy) and is ranked "very strong, liable to cause rashes and sore eyes". (Epoisses de Pieds is banned from public transport in Italy).
• Vial 3 (Red) is based on Peixe-Podre et Meia (Northern Portugal) and is ranked "intolerable, liable to cause vomiting, diahorrea, and heart attacks". (Peixe-Podre et Meia is based on Blue-vein Smegma which had a 97% mortality rate before the EU made its manufacture a federal offense punishable by 25 years imprisonment.)

Believe us when we tell you that once your developers have experienced Peixe-Podre et Meia (Red) they will never again sit idly by while your codebase is merely in Epoisses de Pieds (Amber) state!

10,000 warnings

Suppose you are working on a codebase that has 10,000 warnings. Perhaps you have discussed how you can get rid of the warnings. Perhaps you have discussed it more than once. But you still have 10,000 warnings. What can you do? There is no magic bullet. You are not going to be able to buy a magic tool, or wave a magic wand, and with almost no effort, get rid of them all. If there was you would already have waved the wand.

Even if there was such a silver bullet it would create a shallow improvement, rather than a deep one. It would create no dynamic whatsoever to encourage the developers to learn how not to introduce warnings in the first place. It would do the opposite.

Naturally new warnings keep appearing. Tomorrow there will be 10,001 warnings. But the 1 new warning gets lost in the sea of 10,000 others. It's not even noticed. The number of warnings is trending relentlessly upwards.

The only way you can get rid of 10,000 warnings is the same way you got them in the first place. A little bit at a time. With effort. Effort that shows you care.

The first thing to do is put a finger in the hole. Cap the number of warnings. Make new warnings count as errors from now on. Don't just say "new warnings count as errors from now on". You said that last time and it didn't work. Alter the way you build your software so that new warnings cause a build failure. If module X has 3,663 warnings then 3,663 is the stake in the ground. If it gets more than 3,663 make that a build failure.

This creates pressure to remove warnings on the code actually being worked on. In a culture where warnings are ignored to the extent that they've grown to be 10,000 strong, developers are not likely to see the merits of removing warnings from old code that seems to work and no one has touched for a long time.

Once the number of warnings has stabilized, or even started to trend slightly downwards, you can work on reducing the number of warnings. If the maximum number of warnings in the build is currently 10,000 then set a target. Agree that in a weeks time the number will have dropped to 9,900. Or agree to look at the classes of warnings and target the worst one.

You don't have to get to zero. Getting to zero would mean removing warnings from old code that hasn't been touched for ages. That's not as important as changing the dynamics of the how people act so that the number of warnings is going down rather than going up.

Once you get to a level your happy with, don't turn the build-checks off. Don't take your finger out of the hole. If you do that warnings can easily start to rise again. Leave them in place.

Once you get to a level your happy with, look at ways you can improve further. Buy new tools that detect new warnings. And start again. Focus on improvement not perfection.

Quality Software ManagementVol 2. First-Order Measurement

is the title of an excellent book by Jerry Weinberg (isbn 0-932633-24-2). This is the second snippet review for this book (here's the first). As usual I'm going to quote from a few pages:

The update cycle on the project control panel should be scaled to something less than the longest period of time the project can afford to be late.

Large projects always fail when their communication systems fail.

The slowdown of fault removal is a major reason why project times are underestimated.

In the end, it's not the observation that counts, it's the response to the observation. That's why Zen masters teach patience in response.

Culture makes its presence known through patterns that persist over time.

What power corrupts most thoroughly is the ability to make meaning of observations.

Incongruent behaviour is the number one enemy of quality, because it disguises what people truly value.

If you can see it you can review it.

The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 [Routine] to Pattern 3 [Steering].

In my consulting, I frequently talk to managers who seem obsessed with cutting the cost of software or reducing development time, but I seldom find a manager obsessed with improving value.

No other observational skill may be more important to software engineering than precision listening.