The Humble Programmer

by Edsger W. Dijkstra, 1972 ACM Turing Award Lecture:

We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad of cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worthwhile to point out that the purpose of abstraction is not to be vague, but to create a new semantic field in which one can be absolutely precise.

The tools we are trying to use and the language or notation we are using to express or record our thought are the major factors determining that we can think or express them at all!

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility.

Programming will remain very difficult.

The best way to learn to live with our limitation is to know them.

In computer programming our basic building block has an associated time grain of less than a microsecond, but a program may take hours of computation time. I do not know of any other technology covering a ratio of 10^10 or more.

This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation; it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

Patterns of Software

is the title of a truly excellent book by Richard Gabriel. I reread this every year or so. Each time it speaks to me with new depth and wisdom. As usual I'm going to quote from a few pages:

My overall bias is that technology science, engineering and company organization are all secondary to the people and human concerns in the endeavor.

Compression is that characteristic of a piece of language in which each word assumes many meanings and derives its meaning from the context.

What [D'Arcy] Thompson insisted on was that every form is basically the end result of a certain growth process.

The process of software construction is the single most important determining factor in software quality.

Methodologists who insist of separating analysis and design from coding are missing the essential features of design: The design is in the code, not in a document or in a diagram.

Poincaré; once said: "Sociologists discuss sociological methods [not sociology]; physicists discuss physics [not physics methods]." I love this statement. Study of method by itself is always barren.

Study software, not software methods.

If we hope to make buildings in which the rooms and buildings feel harmonious; we too, must make sure that the structure is correct down to ¹/₈^th of an inch.

To get wholeness, you must try instead to strive for this kind of perfection, where things that don't matter are left rough and unimportant, and the things that really matter are given deep attention.

Without large structure, the design cannot hold together; it becomes merely a jumble of isolated design elements.

The nature of a system is such that at almost granularity it looks the same; it is a system.

In the modern era, we have come to favor simplicity over complexity, perfection over imperfection, symmetry over asymmetry, planning over piecemeal growth, and design awards over habitability. Yet if we look at the art we love and the music, the buildings, towns, and houses, the ones we like have the quality without a name, not the deathlike morphology of clean design.

Slack

is the title of an excellent book by Tom DeMarco (one of the authors of Peopleware). As usual I'm going to quote from a few pages:

The more efficient you get, the harder it is to change.

The survival tactic that Harry and others like him hit upon when their buffers begin to empty is to slow down.

The principal resource needed for invention is slack.

The purpose of the schedule was planning, not goal-setting.

You need to understand that management is utterly essential. It is.

Quality takes time.

You're efficient when you do something with minimum waste. And you're effective when you're doing the right thing.

When you're not safe, you feel afraid. And fear can inhibit change.

I see one pattern common to all winners. They acquire trust by giving trust.

We tend to resist learning things that really matter.

Most of us don't learn well from abstraction. We learn from example.

Training - practice by doing a new task much more slowly than an expert would do it.

Managing your risks requires that you go at some slower speed.

cyber-dojo seems to work as planned!

I'm hoping to run at least one cyber-dojo as a birds-of-a-feather session at the upcoming accu conference. cyber-dojo allows you to perform code-katas using a web browser front end. To make sure it all works as planned I connected a client and a server together via a switch+router. It came together fairly painlessly! cyber-dojo is written in ruby and rails served by passenger and apache2 all running in an Ubuntu VirtualBox inside the MacBook on the right. The client on the left is Firefox on an MSI netbook also running Ubuntu.

Book mark granularity

Many years ago I noticed a problem with regular bookmarks. Quite often I'd open the book and waste some time trying to figure where on the page I'd already read to. One solution was to mark the exact place. That worked quite well but sometimes I didn't have a pen or pencil to hand. Then I realized there was a much better, much simpler solution. Use a post-it of some description and stick not to the top of the page but to the side thus marking not just the page, but also the line I'd got to. Simples!

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

Almost all behaviour is learned

I've just started reading Drawing on the Right Side of the Brain by Betty Edwards. She writes...

It's sometimes necessary to remind ourselves that Shakespeare at some point learned to write a line of prose, Beethoven learned the musical scales, and as you see in the margin quotation, Vincent Van Gogh learned how to draw.

And the margin quote is from a letter written by Vincent Van Gogh to his brother...

...at the time when you spoke of my becoming a painter, I thought it very impractical and would not hear of it. What made me stop doubting was reading a clear book on perspective, Cassange's Guide to the ABC of Drawing: and a week later I drew the interior of a kitchen with stove, chair, table and window - in their places and on their legs - whereas before it had seemed to me that getting depth and the right perspective into a drawing was witchcraft or pure chance.

More beauty in the detail

Tiny tiny plants are growing in the wall on the walk to Patrick's school.

Projector shadows

If you use a projector it's a good idea to let it do its job. Accidentally standing in front of the beam will obscure parts of the projection and annoy your audience. An effective, low-tech solution to this problem is a roll of masking tape! Simply mark out no-go areas on the floor between the projector and the screen/wall.

Writing left handed

In Dan Pink's book Drive he mentions a publication called ambidextrous. This got me thinking it might be fun to learn to write left-handed (I'm right handed). Every week or so I've been copying a short paragraph with my left hand and taking a photo the resulting scrawl...

What's missing in this UML inheritance?

Answer - the interface client...



That's better!

Upside down UML inheritance

Here's how inheritance is typically drawn in UML.



When the top two classes are in one package and the bottom class is in another package the effect is to create a package dependency pointing upwards (think of the inheritance triangle as a fat arrowhead). It's odd that this style for drawing inheritance is so dominant as it is in stark contrast to how package/layer dependencies are typically drawn - pointing downwards. The solution is simple - rotate the diagram!



However, associations are conventionally drawn left to right. Again the solution is simple - this time the diagram needs a reflection!

The Aremac Project

Is the title of a great science-fiction book by Jerry Weinberg (yes, the same one who wrote The Psychology of Computer Programming and The Secrets of Consulting - among many others). I really enjoyed reading this - the story moves along at a brisk pace and is full of invention. Sometimes the ideas seem so plausible you wonder if they are actually true. And some of them are! For example, Jerry assures me that dogs can and are trained to help owners cope with fits in exactly the way he describes towards the end of the book. Amazing. There's a clever twist in the title too which you might spot. Definitely recommended.

Drawing, Learning, Art

I spotted the following three terms from the glossary of Drawing on the Right Side of the Brain. They could be straight out of a software glossary!

Learning: Any relatively permanent change in behaviour as a result of experience or practice.

Composition: An ordered relationship among the parts or elements of a work of art. In drawing, the arrangement of forms and spaces within the format.

Abstract Art: A translation into drawing, painting, sculpture, or design of a real-life object or experience. Usually implies the isolation, emphasis, or exaggeration of some aspect of the artist's perception of reality.

More lift problems

Almost Instant Learning - Not

Fast track management. And an MBA in only 80 minutes! Just two of the many books spotted in the "instant learning" section of an airport bookshop. No thanks.

Beauty in the detail

Lichen covered bricks in an old weathered wall on the way to school.

Accu charity book giveaway

My wife and our three kids live in a fairly small end-terraced house. My work-related books are taking up too much space so I'm going to give a load of them away at this years ACCU conference. My plan is to choose a charity and ask everyone who takes a book to make a voluntary donation. I've already collected one boxfull. If you're coming to the conference maybe you'd like to consider contributing some books too?

The Five Dysfunctions of a Team

is the title of a great book by Patrick Lencioni. The subtitle is "a leadership fable" and pages 1-185 form a story of how a new CEO starts to turns around a dysfunctional group of individual high achievers who are not pulling together as a team. Each "chapter" is rarely more than four pages long and the story moves along at a brisk and enjoyable pace.

The last forty odd pages explain the five dysfunctions model:

1. Absence of trust (invulnerability)
2. Fear of conflict (artificial harmony)
3. Lack of commitment (ambiguity)
4. Avoidance of accountability (low standards)
5. Inattention to results (status and ego)

Just one quote this time:

Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.

More name games

Here's another way for a new group of people to find out each others names and start to become a team:

1. Ask each person to write a very brief bio on a piece of card.
2. Collect in all the cards.
3. Choose pairs by randomly picking two cards (if there is an odd number have one group of three).
4. Pairs have to introduce each other by reading from the cards. Do this immediately so that if the writing is illegible they have to talk to each other to decipher the words.
5. Ask everyone to stick the cards onto a board, and arrange them in a pattern to reflect where they are sitting.
6. Ask everyone to spend a few minutes huddled around the board reading the cards.
7. Repeat whenever you need to shuffle the pairs.

Reverse numbering?

The Thistle Hotel, Barbican, London.

Family writeboards

I'm self employed and work from home a lot. I have a small whiteboard stuck to the wall near my desk which my son Patrick enjoys writing on. So I bought another mini whiteboard for him. I hadn't planned it - but gradually the whole family has starting writing little messages on his whiteboard. As my children grow up (I also have two teenage daughters) they're leading increasingly independent lives and we seem to all be in the house at the same time less and less. The whiteboard provides a simple and direct way to chat asynchronously. And I think that helps them express themselves more freely. I also bought a divers slate so I could jot ideas down as they come to me in the shower. They've adopted that too!

How do you paint lamp-posts?

Design them so you can fold them over!

Norwegian Developers Conference submission

I made a joint submission with Olve Maudal to the Oslo NDC conference over the weekend. Here it is:

Title

cyber-dojo : a code dojo for seriously improving your development ability

Short Abstract

The usual format for a code dojo is fairly well known: participants split into small groups, each group codes on their own laptop, all groups work on the same coding exercise with keyboard drivers rotating within the each group periodically. Towards the end of the dojo the coding stops and everyone presents their work in turn. This form of practice is often called a kata.

A cyber-dojo is different in one important respect: each group still has their own laptop but they all perform the kata completely inside a web browser. A dedicated cyber-dojo server hosts the kata, saving the source files (and the outcome of running the tests) every time the run-tests button is pressed in the browser. Running a code-dojo in this manner creates many new exciting benefits:

1. starting the kata is virtually instant - participants do not need anything installed at all.
2. all the step-by-step incremental run-tests submissions can be inspected helping to place a much greater emphasis on the decisions taken during the kata rather than simply the code at the end of the kata.
3. the cyber-dojo server allows everyone to peek at the current submissions of all groups!
4. since all development environments are now identical it is even possible to introduce timeboxed iterations to the kata and rotate codebases at each iteration!
5. it speeds up the end of kata retrospective (since you don't have to physically involve each individual laptop).

The aim of a cyber-dojo is to introduce deliberate practice to software development. The talk will explain the nature of deliberate practice, demonstrate a live kata using the cyber-dojo server, and give away copies of the server software to anyone who would like to run their own cyber-dojo.

Outline

1. explain what deliberate practice is and how it differs from plain practice
2. remind everyone how a standard code dojo is run
3. introduce cyber-dojo and explain how it is different
4. reveal the new exciting code dojo possibilities cyber-dojo creates
5. performing a small live cyber-dojo kata
6. short questions and answers session
7. give away the cyber-dojo server software to anyone interested

Level

All

Expected audience

Anyone who is serious about wanting to improve their coding ability!

Names

1. Jon Jagger, jon@jaggersoft.com
2. Olve Maudal, olve.maudal@tandberg.com

Biographies

1. Jon Jagger is an independent software coach-consultant-trainer-enthusiast based in England. He specializes in agile software development (people, process and principles), test driven development, deliberate practice, design, analysis, OO, UML and curly bracket languages. He served as the convenor and principal UK expert on the ECMA C# committee and has co-authored two books on C#. He is a frequent visitor to Oslo and has presented at the Oslo C++ User Group and JavaBin. He is a regular speaker at the Accu conferences. You can follow him at http://jonjagger.blogspot.com/ and http://twitter.com/JonJagger He is 43, married with three children. He loves freshwater river fishing.
2. Olve Maudal loves to write code, but is perhaps more interested in how software is developed than what it actually does. Since 2004, Olve has been working for TANDBERG, the leading provider of telepresence and video conferencing products and solutions. Previous experience includes developing systems for finding oil (Schlumberger 1996-2000), and developing systems for electronically moving money (BBS 2000-2004). Olve is an active member of the vibrant geek community in Oslo where he is involved in JavaPils, Cantara, XP Meetup, Oslo C++ Users Group, Lean Meetup and a few other things. You can follow him at http://olvemaudal.wordpress.com and http://twitter.com/olvemaudal

Notes to the program committee

1. If there is demand I will happily run cyber-dojo's outside scheduled talk time.
2. http://vimeo.com/104548135 is a video demoing cyber-dojo which should give you a feel for it.
3. http://github.com/JonJagger/cyberdojo hosts the open-source cyber-dojo git repository

Magic numbers and beyond

Are all magic numbers bad? To give the classic consultants answer - it depends. Take zero for example. If the zero is being used as an index into an array then the zero is a zero because all arrays start at zero. That's internal knowledge; knowledge that is part of the solution and a reflection of something from the problem. There is no way you can conceive of a change in the problem causing a change to that zero. So it's internal. So it's ok. But all things are relative. It might still be a good idea to refactor - to a higher level expression of the iteration perhaps. But most numbers are not internal, they come from the problem. If numbers such as this are not named then they are indeed magic numbers; they are numbers that reveal nothing of their origin.

Magic isn't limited to numbers though. Far from it. A magic number is a number and a number is an expression. So a magic number is also a magic expression. And of course, all expressions lie on the same magic-code continuum; some expressions are very intention-revealing, they're not very magic at all - while other expressions are very cryptic and thus qualify as magic expressions regardless of whether they contain numbers or not.

Beyond magic expressions we have magic statements, magic functions, magic classes, you name it, if its part of the code it can be magic. I think it's time we pushed the word magic into greater service. It's time we had a better vocabulary for hard to understand things. If you see a hard-to-understand X in code how about calling it a magic X.

Snow on rock pattern

At the bus-stop on Frederick's Gate, Oslo, while waiting for the 151.

The name game

When I'm training/coaching a group of people I often haven't met any of them before and sometimes they haven't met each other either. So one of the first things we all have to do is get to know each others names. It can be boring and painful asking each person to briefly introduce themselves so here's an alternative...

Instead, announce that you want everyone to write their name on a flipchart (or whiteboard) and that you're going to time how long it takes. Your mobile phone probably has stopwatch feature (if not just count out loud). Then just say "go" and start the stopwatch. Some people will be puzzled and just sit there doing nothing for a while, but eventually everyone will realize you really mean it! When they've finished and sat down again tell them how long it took, comment on the illegibility of their writing, prepare a new sheet of paper on the flipchart (or wipe the whiteboard), and ask them to do it again making it clear that this time you want it done faster. And legibly! You have to be able to read the names! Say "go" again and restart the stopwatch.

You can easily and quickly repeat this up to ten times. You can allow a little retrospective time between iterations if you like. You can insist that the names are drawn in a way that bears some relation to where they're actually sitting. The variations are endless. The ingenuity shown by the groups when I've run this is often remarkable. They easily get the time down from about 2 minutes to a few seconds. I've also found it works very well if you rerun the exercise every morning (perhaps after hiding most of the pens ;-)

Quite by chance I've learned that my friend Henrik Kniberg has been using peoples names as the theme for a similar group exercise.

UML modelling with fridge-magnets

Whiteboards are a great UML case tool. They help to make modelling a social activity. They help to emphasize that the act of modelling and the understanding it produces is just as valuable as the resulting model. The wipeability of whiteboards is also a great feature. It encourages modification and experimentation.

Whiteboards are not so good when you want to rearranging a diagram though. But... it occurred to me that if the whiteboard is magnetic then fridge-magnet-style UML-shapes might help. So I found a company that sells magnetic sheet and paid a bit extra to have it coated with a dry-wipe surface. The first sample arrived today and I've made my first prototypes. I cut out two sizes of rectangles and edged them with a permanent marker. Here's one of the larger ones (the background is a tablecloth not wallpaper!)



Now simply stick them on the whiteboard - they stick to each other of course:



Here's the big rectangles vertically in 3-section class format:



And horizontally for packages (just draw on the top-left tab):



Here's a 1-section only class diagram overview made from the smaller rectangles:



And just for Pete Goodliffe here's a Booch cloud:



I'm also going to cut out some ellipses for use-cases/scenarios and some rounded rectangles (roundtangles) for activities/states.

Dan Pink's challenge to draw yourself in just 5 lines

typedef in C

I regularly coach advanced C to the great engineers at Tandberg in Oslo. One of the topics we've discussed is typedef style. For example

• not using typedefs (Linux kernel style) like this

struct wibble;

void wibble_this(struct wibble *);
void wibble_that(struct wibble *);

• or with typedefs, like this

struct wibble;

typedef struct wibble wibble;

void wibble_this(wibble *);
void wibble_that(wibble *);

This matters because typedefs are not idempotent in C, which is to say you can't write this

typedef struct wibble wibble;
...
typedef struct wibble wibble; // non-conforming duplicate

A C file has its #includes and these #includes will have their own #includes, ad infinitum. It can be tricky knowing whether a type has already been typedef'd or not, and hence whether the C file has to declare its own typedef or not (for example, when forward declaring the type). However, there is a style that neatly avoids this problem

• in header files don't typedef

// wibble.h
struct wibble;

void wibble_this(struct wibble *);
void wibble_that(struct wibble *);

• in source files do typedef

// use.c
#include "wibble.h"

typedef struct wibble wibble;

void eg1(wibble * w)
{
    ...
}

void eg2(void)
{
    wibble * w = ...
    ...
}

This is somewhat similar to the C++ rule that header files always use explicit :: qualification. My friend Kevlin Henney commented that the idea is also resembles using typedef's in the private section of a C++ class which is a nice observation. I haven't tried this on a large codebase. At the moment it's just an idea. Caveat emptor.

I hope you don't want floor 7

In a hotel in Beijing. I wonder what the words say? "Please press the buttons gently" perhaps?

Use-Case cartoon speech bubbles

UML Use Case/Scenario ellipses look quite similar to cartoon speech bubbles. And each ellipse is of course supposed to be "spoken" by an actor. So sometimes when I'm coaching/training/etc I cut out ellipse shaped pieces of card and do some role playing.



You can have fun too. For example, developers often phrase their use-cases from the implementation perspective rather than from the actor's perspective. So when they write "Lend a Book" as the name of their Use Case, you can get them to actually try it. Pretend your inside a library, give them a book, and ask them to role play their use case. Like this... (the headband stops their arms from aching)



At which point someone role playing a Librarian can react like this...



...which makes everyone realize they should really have written this:

Talent is Overrated

is the title of another excellent book (isbn 1857885198) by Geoff Colvin. As usual I'm going to quote from a few pages:

Deliberate practice is not what most of us do when we think we're practising.

Most organizations are terrible at applying the principles of great performance. Many companies seem arranged almost perfectly to prevent people from taking advantage of these principles for themselves.

nothing, it turned out, enabled any group to reach any given grade without putting in those hours. ... There is absolutely no evidence of a 'fast track' for high achievers.

memory ability is very clearly created rather than innate.

General Electric CEO Jeff Immelt has been clear about what the company is looking for: someone who is externally focused, is a clear thinker, has imagination, is an inclusive leader, and is a confident expert.

The roadblocks we face seem to be mostly imaginary.

Jerry Rice was the greatest because he worked harder in practice and in the off-season that anyone else; he spent very little time playing football; he designed his practice to work on his specific needs; he did much of the work on his own; it wasn't fun; he defied the conventional limits of age.

Practice is so hard that doing a lot of it requires people to arrange their lives in particular ways.

The advantage of practice was cumulative.

Deliberate practice requires that one identify certain sharply defined elements of performance that need to be improved, and then work intently on them.

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.

Practice is designed, so it can be designed well or badly.

Great performers never allows themselves to reach the automatic, arrested-development stage in their chosen fields. The essence of practice, which is constantly trying to do the things one cannot do comfortably, makes automatic behavior impossible.

In fact what they [great performers] have achieved is the ability to avoid doing it automatically.

It's Your Ship

is the title of an excellent book by Michael Abrashoff (isbn 0446529117). As usual I'm going to quote from a few pages:

A recent Gallup study found that when people leave their companies, 65 percent of them are actually leaving their managers.

What I suddenly realized was that I had the power to do this all along. I just never had the self-confidence.

Something happened as a result of those interviews. I came to respect my crew enormously.

Secrecy spawns isolation, not success.

No matter how fantastic your message is, if no one is receiving it, you aren't communicating.

You earn trust only by giving it.

More often than not, bureaucracies create rules and then forget why they were needed in the first place, or fail to see that the reasons for them no longer exist.

Once leadership opportunities are squandered, you can never get them back.

If a rule doesn't make sense, break it.

If a rule does make sense, break it carefully.

I felt as small as a man could. I had just had my core values calibrated by someone half my age.

One-size-fits-all programs tend to fit none.

Leadership is mostly the art of doing simple things very well.

Open yourself. Coldness congeals. Warmth heals.

The goal shouldn't be to reduce the standards for some, but to raise everyone else to the highest possible level.

Train for unity.

If you don't intend to act, then don't bother to ask if it is going on. It will only make matters worse.

I kept walking around the ship, questioning the crew, drawing them out.

Having fun with your friends creates infinitely more social glue for any organization than stock options and bonuses will ever provide.

Heathrow Blue Screen

Classroom summary techniques

A technique I use a lot when teaching/coaching is to get the participants to periodically do a summary. I have two main techniques:

The first technique (which I tend to use for smaller groups) is to ask the group to just shout out anything they can remember. Whatever they call out I write on a whiteboard and we briefly recap that topic. When the calling out slows down we stop. Then we vote; each person places three ticks on the whiteboard. I count up the ticks and we see what the top three are.

For a larger group I ask for just one thing from each person. I make it completely clear that you can choose anything you like for whatever reason you like. When someone calls something out I briefly summarize that topic but I don't write anything down.

In both cases I've found it's important not to simply ask each person, round-robin fashion, based on where they're sitting. It's much much better if you simply wait for the first person to speak, and then wait for the second person to speak, etc. That way the more confident ones naturally speak first and the less confident ones gain confidence by seeing the more confident ones go first.

Deming's knowledge of variation

Mary Poppendeick's excellent InfoQ video is online at http://www.infoq.com/presentations/poppendieck-agile-leadership Her summary of Deming's Knowledge of Variation at around 28 minutes is great and well worth watching.

Tandberg product development

My good friend Olve Maudal of Tandberg did a talk about Product Development in TANDBERG for the Oslo Lean Meetup. His slides are online at http://bit.ly/cxNvjc and are well worth a look if you care about what it takes to make world class software.

The vaccination approach to learning

Thanks to Tobias Fors for tweeting the following onto my radar.

Reading up on how learning works, I came across a couple of quotes on the subject. I particularly like the one about the vaccination approach to knowing - it exposes our fantasy that all it takes is to “send people back to school”, and then everything will be fine.

Explaining the metaphor Tobias quotes Kurt Lewin:

The learners become their own subjects and no longer objects to be filled with packages of knowledge in the manner of what Neil Postman and Charles Weingartner call the vaccination approach to knowing - “where education is something you take and, when you have taken it, you’ve had it, and if you’ve had it you are immune and need not take it again.”

2,390,000 all of a sudden

As a self-employed software coach-consultant-trainer-developer-enthusiast-etc I have to try and market myself. My marketing strategy is simple - I try to do stuff to increase my Google ranking. That's it. I monitor this by regularly typing my name into Google and seeing how many hits it generates. It's been around half a million for quite a while. I don't know why, but this morning it's suddenly jumped to over 2 million!