Alice in wonderland

is an excellent book by Lewis Carroll. As usual I'm going to quote from a few pages:

It was labelled ORANGE MARMALADE, but to her great disappointment it was empty.

Down, down, down. Would the fall never come to an end?

She generally gave herself very good advice (though she very seldom followed it).

Alice felt so desparate that she was ready to ask help of anyone.

Why, said the Dodo, the best way to explain it is to do it.

It sounded like an excellent plan, no doubt, and very neatly and simply arranged; the only difficulty was, that she had not the smallest idea how to set about it.

Would you tell me, please, which way I ought to go from here?
That depends a good deal on where you want to get to, said the Cat.
I don't much care where - said Alice.
Then it doesn't matter which you go, said the Cat.

Have some wine, the March Hare said in an encouraging tone.
Alice looked all round the table, but there was nothing on it but tea.
I don't see any wine, she remarked.
There isn't any, said the March Hare.

The chief difficulty Alice found at first was in managing her flamingo.

Alice soon came to the conclusion that it was a very difficult game indeed.

Take off your hat, the King said to the Hatter.
It isn't mine, said the Hatter.
Stolen, the King exclaimed, to the jury, who instantly made a memorandum of the fact.
I keep them to sell, the Hatter added as an explanation: I've none of my own. I'm a hatter.

Begin at the beginning, the King said gravely, and go on till you come to the end: then stop.

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.

Curry velocity

Some people's introduction to curry begins with them ordering the hottest dish on the menu. They discover the dish is beyond their curry-capacity and they can't finish it. Amazingly, they often repeat this behaviour. Lots of curry goes to waste. Dishes are frequently only half-eaten. Curry velocity remains at zero.

Other people's introduction to curry begins with them trying something nearer the cooler end of the Scoville scale. They find the dish is below their curry-capacity. They finish it! No curry is wasted. Their curry velocity is above zero. The next time they may decide to try something a little hotter. But they are in control of the curry, rather than the curry being in control of them.

Augustine's Laws

is an excellent book by Norman Augustine (isbn 0-670-80942-X). As usual I'm going to quote from a few pages.

First the serious quotes:

To finish first you must first finish.

Little did the Greeks know - the universe actually consists of Earth, fire, water, and software.

The budgeting process resists change.

If you want it bad you get it bad.

We can overcome gravity, but sometimes the paperwork is overwhelming. [Wernher von Braun]

The objective in business, however, is to measure how many undertakings are completed - not how many can be started.

reliability… must be designed into the product by the designer and built into it by the manufacturer - it cannot be inculcated by the quality department.

…the parts which break… are always the ones located in the most inaccessible places. Therefore, only a few mechanics are able to crowd around them simultaneously.

Managers must have the discipline not to keep pulling up the flowers to see if their roots are healthy [Robert Townsend]

and second the funny quotes:

Anybody can have an off decade.

...turned out to be the earliest they had ever been late.

Our team is well balanced - we have problems everywhere.

…trying to leap deep chasms in two bounds.

If it weren't for bad luck he'd have no luck at all.

It's like sending lettuce by rabbit.

There was good news and there was bad news. The good news was that management was buying everyone on the assembly line a turkey for Christmas. The bad news was that they had only ordered ten turkeys.

A knife without a blade, for which the handle is missing. [Lichtenberg]

Lord Barnetson, chairman of the London Observer, has had attributed to him the following anecdote about how a management critic would review Schubert's Unfinished Symphony:

• It appears that for a considerable period of time the four oboe players had nothing to do. The number should be reduced, and their work spread over the whole orchestra...
• All twelve violins were playing identical notes. This seems unnecessary duplication and the staff of the section should be drastically cut...
• Much effort was absorbed in the playing of demisemi-quavers. This seems an excessive refinement, and it is recommended that all notes be rounded up to the nearest semiquaver...
• No useful purpose is served by repeating with horns the passage that had already been handled by the strings...

Henrik Kniberg's name game

Update: Henrik has now written a detailed explanation of how he plays the game here.

Henrik designed the name game to show how the lean idea of limiting work in progress can have a dramatic effect. Here's how you play:
Split into groups of six. In each group there are 5 customers and 1 developer. Each customer has a project - they simply want the developer to write down their name. That's it. During both iterations the following times have to be recorded (to the second):

1. the overall start time
2. the time each customer's project starts (when the developer writes down the first letter of their name)
3. the time each customer's project is delivered (when the developer writes down the last letter of their name)
4. the overall finish time

In the first iteration each developer has to act under the principle of "never keep a customer waiting" and tries to write all the names simultaneously. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for the first letter of their name and writes it down; the first customer's project has started so they write down their project's start time:

1.B       2.        3.        4.        5.

the developer asks their second customer for the first letter of their name and writes it down; the second customer's project has started so they write down their project's start time:

1.B       2.E       3.        4.        5.

the developer carries on until they have written down the first letter of all their customers names; every customer will have written down their project's start time:

1.B       2.E       3.P       4.T       5.J

the developer asks their first customer for the second letter of their name and writes it down; if this completes the customer's name the customer's project is delivered and the customer writes down their project's finish time (Be will become Bert so not yet):

1.Be      2.E       3.P       4.T       5.J

the developer asks their second customer for the second letter of their name and writes it down; again, if this completes the customer's name the customer writes down their project's finish time (El will become Ellie so not yet):

1.Be      2.El      3.P       4.T       5.J

the developer carries on until they have written down the second letter of every customer; Jo is Jo so Jo's project is delivered and Jo writes down her project's finish time:

1.Be      2.El      3.Pa      4.Te      5.Jo

the developer carries on round-robin, letter by letter, until they have written down the full name of all their customers; every customer now has a project finish time:

1.Bert    2.Ellie   3.Pat     4.Terry   5.Jo

Stop the clock and record the overall finish time.

Now the developers swap customers (so they don't know their customer's names once more).

In the second iteration the developers act under the principle of "limit work in progress to 1 customer at a time". So no multi-tasking. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for their whole name and writes it down. When the developer starts writing their name the customer writes down their project's start time, when the developer finishes writing their name the customer writes down their project's finish time.

1.Sally   2.        3.        4.        5.

the developer asks their second customer for their whole name and writes it down. Again, the second customer writes down their project's start and finish time.

1.Sally   2.Russ    3.        4.        5.

the developer continues round-robin asking each customer in turn their full name. All customers now have a project start and finish time.

1.Sally   2.Russ    3.Ed      4.Larry   5.Clive

Henrik writes:

Then we chart the results and compare and discuss. Typically the lead time per customer is at least 5x shorter in the second round, and the total time to do all customers is 3x shorter (so the developer could handle 3x more customers within the same time, and each customer only needs to be engaged in the project for 5x shorter time than before). Most people intuitively believe that, if you start something earlier, you will finish earlier. This exercise brutally murders that misconception :o) A simple exercise, but the effect is astounding.

If you like software-related games you might also like

• Cyber-Dojo
• Kanban 1's Game
• Simplest Name Game