XPlorations

What's the Metaphor?

"The system metaphor is a story that everyone - customers, programmers, and managers -
 can tell about how the system works."
    Kent Beck, Extreme Programming Explained, p. 179.

• Common Vision: To enable everyone to agree on how the system works. The metaphor suggests the key structure of how the problem and the solution are perceived. This can make it easier to understand what the system is, as well as what it could be.
• Shared Vocabulary: The metaphor helps suggest a common system of names for objects and the relationships between them. This can become a jargon in the best sense: a powerful, specialized, shorthand vocabulary for experts. Naming something helps give you power over it.
• Generativity: The analogies of a metaphor can suggest new ideas about the system (both problems and solutions). For example, we'll look at the metaphor, "Customer service is an assembly line". This suggests the idea of a problem being handed from group to group to be worked on, but it also raises the question, "What happens when the problem gets to the end of the line - does it just fall off?" This can bring out important issues that might otherwise lurk and fester.
• Architecture: The metaphor shapes the system, by identifying key objects and suggesting aspects of their interfaces. It supports the static and dynamic object models of the system.

What if the metaphor is "wrong"? You obviously don't want this problem, but all you can do is your best. If you later realize there's a better metaphor, evolve your system in that direction. This can be a very good thing - it means you've made a breakthrough learning in understanding your problem.

What if you can't thinking up any good metaphors? There's always the "naive metaphor" - let objects be themselves. For example, a bank model might have Customer and Account objects. This may not give you any extra insights (since it's based on what you already know), but at least it lets you get started.

What are some system metaphors that have been used?

• A pension tool as a spreadsheet. [Extreme Programming Explained, p. 56]
• A system combining double-entry bookkeeping and a spreadsheet. [Kent Beck, oral communication] {Was this the same as the pension tool?}
• Desktop metaphor for graphical user interfaces.
• Bill of materials in VCAPS. [http://c2.com/cgi/wiki?VcapsProject]
• Lines, buckets, and bins in C3 payroll. [http://c2.com/cgi/wiki?SystemMetaphor]

Example: Customer Service

We'll explore several metaphors that a team might work through, and see the tradeoffs we might make in letting each of these guide the system's development.

The naive metaphor. Customer Service Reps create Problem Reports on behalf of Customers, and assign them to Technicians.

Assembly line. Think of problem reports and solutions as the Assembly, and the technicians as Workers at Stations. This metaphor suggests the possibility that it might take a number of steps or people to solve a problem.

In the naive metaphor, we have to carefully think through the implications of the metaphor. In the assembly line metaphor, the metaphor helps carry our understanding. For example, we might wonder how many items per hour come off the end of the line. This helps us think about the "capacity" of our operation. We might wonder what happens to an item once it hits the end of the line. Perhaps we'll want a policy of notifying each customer of the problem's resolution. We might wonder what happens when a station gets backed up. This might help us identify bottlenecks, and might lead us to think of workers as multiply skilled people who can pitch in where they're most needed.

Some aspects of the assembly line metaphor don't work so well. An assembly line tends to have a relatively fixed structure, while we might want something more flexible. The steps from place to place are typically pre-defined; we might want something that decides routing based on the situation.

Questions like these don't necessarily invalidate the metaphor, but rather help us to explore and understand its limits.

Problem-solving chalkboard. An Expert puts a Problem on the Board. There are a number of Experts sitting around: when anyone sees a problem they can solve (or know how to break into easier sub-problems), they do so. There's a protocol that defines, "Who gets the chalk next?" and "When are we done?"

This metaphor suggests a few potential problems: experts have different skills, and they may not necessarily agree on how to solve a particular problem. The chalkboard may become a scarce resource. The most knowledgeable person may find they're doing all the work. We may have "experts" who aren't as good as they think they are.

Subcontractors. The rep is the General Contractor, with control over the whole Job. They can let work out to Subcontractors (who can delegate to others).

This model treats the rep as a critical part of the process: the customer's advocate. Commitments and sub-commitments are tracked. Time bounds (service level agreements) can be built into the contracts. It leaves someone responsible overall, ensuring that problems don't fall through the cracks.

Workflow. Workflow is a generalization of the assembly line, to support an arbitrary graph of possible transfers, along with the idea of dynamically determining what step is next. It is in effect a semi-standardized version of the naive model.

The concept of workflow may not be a part of some peoples' mental framework. Even if it seems like a perfect fit based on the problem, it may not be the best choice if it won't give people any intuition about the system. (I find it a little abstract for a metaphor, but it might be just right given the right group of people.)

Conclusion. We've discussed several potential metaphors: naive, assembly line, chalkboard, subcontracting, and workflow. Each of these brings a different perspective on the interplay of people and problems. The team needs to consider the strengths and weaknesses of each possible model, and select the best fit they can.

Example: Editors

Card. An early editor style was to imitate punched cards: some number of lines, with 80 characters each. This was easy to implement, with a simple array of characters. Users had to confront the question, "What happens when your text is longer than a line?"

Array of Lines. Another model was used by other editors: make each line stand on its own, with any length it needs. Again, implementation was simple: an array of pointers to variable-length lines.

String. Initially used by TECO, and inherited by EMACS: the text is a giant string (with some character as a line separator). Lines could easily be of different lengths. This metaphor easily supports many operations (such as multi-line searches) that could be tricky in the preceding models.

Sequence of Runs. The previous models are adequate for simple text, but something more complicated is needed to support styles. One solution is to regard the text as a sequence of strings, each with the same style. So,
    This is a bold and bold italic text string.
might be encoded as:

This is a	(Regular)
bold and	(Bold)
bold italic	(Bold and Italic)
text	(Italic)
string.	(Regular)

Notice that each combination of styles is treated as a different run, and that runs don't overlap. This metaphor gives a natural view to the meaning of selecting text and applying a style.

Tree. Another editor style is more tree-based, for hierarchical data. This was common in some Lisp editors (years ago), and also used in "structure-aware" or "syntax-directed" editors. It shows up as an outline view in some editors. Today, it's a common model for editing HTML and XML: since they require properly nested tags, the nodes form a hierarchy. Tree editors have powerful operators for locating and re-arranging hierarchies.

Combination. Editors often combine these modes: a tree view may be built out of a string view, and vice versa. A purely tree-based editor may have simple text editing inside, and so on. A combination metaphor may be best, but make sure the combined power is worth the possible confusion it may cause.

Conclusion. Each of these models has been used in real editors. The right metaphor provides the explanatory power you need, in a model that all parties understand.

Limits of Metaphors

• The metaphor may not be familiar enough to the group that needs to use it. Double-entry bookkeeping may be the perfect metaphor, but if the accountants understand it and the programmers don't, it won't be a good system metaphor. (This may mean you need to find a new metaphor, or work to help everyone understand it, etc.)
• We may be working with a too-weak metaphor, one not powerful to explain the critical aspects. For example, if we're developing a distributed system, a metaphor that treats it like a simple uni-processor may not be sophisticated enough to explain things like network delays or failure of remote nodes.
• We may be working with a metaphor that unduly limits our conception of the system. Ted Nelson, of hypertext fame, argues that a spreadsheet had to be understood as a new sort of thing; in effect he argues that the metaphors provide only a shadow of its true nature. (Cited in Coyne, Designing Information Technology in the Postmodern Age, p. 251.) The metaphor in this case may adequately explain what the system is, but not what it could be.
• Many metaphors may be of the form, "it's like a magic xxx" ("a magic typewriter", "magic paper", etc.). This is a two-edged sword. On the up side, it helps us capture some of the extra capabilities our system provides. On the down side, the point where we need the most help ("the magic") is exactly the part that's not covered by the metaphor. Alan Kay, Bruce Tognazzini, and Randall Smith discuss these issues (Kay in Coyne, op cit., p. 252; Tognazzini in Tog on Interface; Smith in "Experiences with the Alternate Reality Kit: An Example of the Tension between Literalism and Magic", IEEE Computer Graphics & Applications, Sept., 1987).

Summary

The metaphor provides a common vision and a shared vocabulary. It helps generate new understanding of the problem and the system, and it helps direct the system's architecture.

We demonstrated how a couple different systems might explore a variety of metaphors, by brainstorming a few and comparing their world-views.

Finally, we discussed some limitations of metaphors.

Resources

• Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 6.
• Extreme Programming Explained: Embrace Change, Kent Beck.
• Designing Information Technology in the Postmodern Age, R. Coyne, 1995.
• Tog on Interface, Bruce Tognazzini, 1992.

[April 15, 2000]

Copyright 1994-2006, William C. Wake - William.Wake@acm.org