Cliches and proverbs prove successful system metaphors

Posted on August 10, 2009



I wasn’t planning to keep up a running commentary on this year’s software engineering class (see last year’s), but already it is taking some interesting turns – so here’s some more.

The classes are working with the Dunedin 350 campaign organisers  (see earlier).  As usual, students are struggling with the idea that they “don’t have a project” – they do have a project  “providing system development expertise to the Dunedin 350 campaign” – but this always comes as a shock after nearly two years of precise instructions in assignments.

So in the first iteration, the focus is on understanding the problem (or opportunity) rather than leaping straight to solutions.   As part of this, we use a system metaphor approach, leading directly to planning game.

One class had a useful discussion about potential metaphors.   We talk about standard metaphors – the shopping cart and so on.  The groups then independently work up their own metaphors, coming together occasionally as a class to compare notes.   Ideas considered included:

– training for a marathon

– easy as ABC (which they extended to learning to read)

– weightwatchers

– role playing game.

The second class took quite a different approach.  I must have said something differently as all the groups independently came up with metaphors that were inspired by proverb ad cliche rather than the structural metaphor we are used to seeing from computing students:

– look before you leap

– play with the cards you were dealt

– focus on your own backyard before finding fault with others

– you can lead a horse to water but you can’t make him drink

– fly to the moon

–  the frog in the pot

– you reap what you sow

– turning the tide

– leading the blind

– keep your fork on your own plate.


We then use the descriptions of the metaphors to generate functional requirements in the form “The <named user> wants to …”.   Usually it is quite hard getting the students beyond  thinking about details of a potential implementation,  but these proverb metaphors worked really well for getting at the problem – what the various users want to be able to do.

We then went though the planning game to rank the function requirements.