views:

409

answers:

5

'Metaphor' seems to be one of the least understood precepts of XP (Extreme Programming) although its supposed to be (one of?) the most important.
Its diff to grasp and supposedly 'the bulb over your head when you get it'. Metaphor seems to be a front for 'programming is a mystic art'.. the others are easy to follow relatively. I've read quite a few books and then some.. but it remains hazy.

  1. So how do I identify a metaphor for the System under development?
  2. How do I know its a good one? What makes a good metaphor good? edit-clarification: Can a bad metaphor do more harm than good?
  3. What does it enable?
  4. How do I get good at metaphor finding... or better than I am currently?
+2  A: 

There is a paper here. But a good example is this one

The metaphor has two purposes. The first is the communication described above. A user
ought to have an easier time speaking and giving examples about a “chameleon” than
about a window that changes transparency. A second reason is that the metaphor is
supposed to contribute to the team’s development of a software architecture.

As for finding one, ideally finding a metaphor for your project should be something really easy. What I mean by that is the metaphor should be something trivial that anyone can understand, even someone with no technical knowledge or even any idea about your system in particular (like the example of the Chameleon).

As for some benefits (lifted directly from the paper)

- The metaphor has been helpful in figuring out the overall design of the program.
- The metaphor has helped the team find a common vocabulary.
- We often use the metaphor in conversations with each other.
- We often use the metaphor in conversations with our customer.
- The metaphor is useful in helping everyone reach agreement about our
requirements.
Robert Gould
Well the paper seems to have dismissed metaphor as 'almost Snake oil' :) Could it be that they didn't know or get the concept?
Gishu
+1  A: 

The idea of a metaphor in Extreme Programming is to develop a common vision of how the program works. At its best, a metaphor is a simple evocative description of how the program works.

From Agile Business Coach:

Metaphors are a powerful teaching tools. They are used in a large number of fields. The aim of a metaphor is to create a bridge of understanding : The person trying to explain a new idea or concept attempts to find a common frame of reference between themselves and the person they are explaining the idea to. They then explain the new idea using the common frame of reference

Now on to your questions.

So how do I identify a metaphor for the System under development?

A good metaphor can quickly provide enough information to understand at a high level the domain and functioning of a system. As example we can say "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system. So you should strive for analogies with real world situations as they are more likely to be understood more quickly and everyone can get in the same pace regarding the system functionality.

How do I know its a good one? What makes a good metaphor good?

The idea is to use a common system of names or analogies to be sure that everyone understands how the system works and where to look to find the functionality you're looking for, or to find the right place to put the functionality you're about to add. A metaphor is more good as more users in presence of a metaphor get an immediate glimpse and understanding of the system.

What does it enable?

It enables rapid minimum global understanding of the system purpose and functioning based on common terminology that everyone can understand more easily.

How do I get good at metaphor finding... or better than I am currently?

With practice and continuous improvements. Make sure that every iteration is shown to a significant mass of persons to assess the efficiency of the metaphor. Along the way you will learn much and get to quickly write good metaphors. I consider it a living exercise almost because the persons with more living experiences can provide more meaningful metaphors without even realizing they are doing so.

See here for a detailed article on XP that also covers metaphors.

smink
A: 

Metaphors allow the team to have a common understanding of the project. It a useful tool to get through the miscommunication barrier which almost any team tend to have due to the different backgrounds/perspectives. You don't have to use them but it helps, especially when you work in an area or on a type of application your developers have no prior experience of. To me a good example of the methaphor is the famous tree swings picture. The developers never worked to deliver the 'tire swing' because the proper metaphor was never found. In this sense the concept of metaphor is a little bit similar to the concept of Vision in RUP but as far as I understand it's focused more on the technical side of the development.

Responding to your questions:

  1. Try to find something which to you describes the system nicely. If I would try to do that I would try to describe the major components separately.
  2. See if it sticks. If everyone immediately understand what you're talking about it works. If it does not - try something else. You have to see a 'spark of recognition' in the team eyes.
  3. The use of metaphor allows everyone to see the application/application architecture from the same prospective.
  4. It really depends on the way you think. Metaphors are poetic and 'soft' - you might never want to become good with them :) I would suggest reading more 'fiction'-type books as they help your mind to get more information for the metaphors

And remember - a metaphor could not be stretched indefinitely. Do not expect them to be ideal.

Ilya Kochetov
+1  A: 

Metaphor is something you start using when your mother asks what you are working on and you try to explain her the details. How you find it is very project-specific. Use your common sense or find the guy on your team who is good at explaining technical things to customers in a way that is easy to understand.

What XP suggests in my opinion are the following:

  • Try to design a system that is easy to explain using real-life analogies. Your systems are complex, try to use a design, where the relationship and interactions between sub-components are clear and resemble something that people with common sense have already seen.
  • Use the analogies in all communications: source-code, planning meetings, speaking to users, or God forsake, writing documentation. If you find that the concepts you use do not fit to some area, try to find a better metaphor.

If you are having troubles introducing a metaphor, maybe the problem is somewhere else. You might have a design not suitable for XP, or you might have a company culture where for example developers use a different language than marketing guys. Both project attributes you can easily live with and carry your project to success, but it will be more difficult to embrace XP unless you make a change in these areas.

wigy
What is a 'design not suitable for XP'?
Gishu
A: 

Well I researched the question for slightly over a day and came up with a slightly better (than when I posted the question) take on metaphors. It turned out to be a bit long.. so didn't include it here and posted on my blog. JFYI.

http://madcoderspeak.blogspot.com/2008/10/who-moved-my-metaphor.html

Gishu