Metaphor

The font for this agile flash card is Lavos Handy

Of the XP practices, the practice of Metaphor seems to be the most widely argued and misunderstood. Simply put, it is a shared understanding of how the system should work. It serves as the oversimplification that "everyone knows" and against which changes can be discussed intelligently.

It may literally be a metaphor, such as a description of a hive of bees or an assembly line or blackboard, but it may also be a more literal description of the basic entities of the system and their interactions (ie not metaphorical at all). The shared understanding is the thing.

The metaphor is:

• A shared theory of system operation from which additional features may be discussed intelligently. If the system is like a spider's web, then we can talk about strands being moved and the spider waiting. If it is like an assembly line, we can talk about stations near the end of the line and the constant feed of parts. If it is like an accounting system, we can talk about double-entry accounting. The importance of the metaphor is partly that it provides a back story for further development.
  
• A model of the system's primary entities and flows can be sufficient shared understanding if the solution is relatively straightforward and can be easily-enough digested. In this way, the business domain of a sufficiently transparent system may be its metaphor(!).
  
• A shared system of names is provided by the metaphor. In a beehive system, workers and drones and queens may serve as class names or database tables. In a petri net, it may be tokens and places. I personally suggest a more straightforward naming style, but a metaphor can certainly be a rich source of meaningful names.
  
• May be an actual metaphor or story that is well-known to the development team. If the system can be well-understood by comparison to a nest of termites or a storm system or trash collection then (as far as it goes) the metaphor can be at the core of all implementation decisions and requirements discussions.
  
• May be replaced or rejected when the system, through evolution of an implementation, ceases to have a compelling resemblance to the orginal metaphor. Remember this when choosing names. The metaphor may still have paid for itself by simplifying earlier requirement and design discussions, and a new metaphor may have at least as much descriptive power. There is no requirement that one cling to an inappropriate metaphor.

The point of the metaphor is that it is supposed to make it easier to think about and discuss the implementation of a system relative to its requirements. Having a metaphor can certainly aid in development of new features, especially in the early days of a software project.