Tag Archives: metaphor

The System Metaphor Explored

The System Metaphor is one of the less popular parts of Extreme Programming (XP). Newer descriptions often even omit it. But metaphor is useful – when you have  a good one, it really helps you understand and organize your system.

This post has a couple versions of a tutorial that Steve Wake and I developed and presented at some of the early Agile conferences. It's released under Creative Commons CC-BY-SA.

Versions: PPT, PDF (2-up), PDF with notes

Thee's also a SlideShare version

Extreme Programming Explored

 

Extreme Programming Explored Extreme Programming Explored, by William C. Wake. Addison-Wesley, 2001. Foreword by Dave Thomas (The Pragmatic Programmer).

This book grew out of the XPlorations series of articles. I wrote them as I was learning XP, and relating it to my own experience and practices.

Availability

The best version is the book itself. It reflects the feedback of reviewers and editors. You can purchase it somewhere like Amazon.com.

The XPlorations series continues to grow. 

Table of Contents

Preface

Chapter 1. Introducing XP…………………………………….1
Programming, team practices, and processes.

Section 1: Programming

Chapter 2. How do you program in XP?…………..11
XP uses incremental, test-first programming.

Chapter 3. What is refactoring?………………………….29
"Refactoring: Improving the design of existing code."
–Martin Fowler

Section 2: Team Practices

Chapter 4. What are XP’s team practices?………51
We’ll explore these practices and their alternatives.

Chapter 5. What’s it like to program in pairs?..65
Pair programming is exhausting but productive.

Chapter 6. Where’s the architecture?………………..77
Architecture shows up in spikes, the metaphor, the first iteration, and elsewhere.

Chapter 7. What is the system metaphor?………..87
"The system metaphor is a story that everyone–customers, programmers, and managers–can tell about how the system works."
–Kent Beck

Section 3: Process

Chapter 8. How do you plan a release?
What are stories like?
………………………………….101
Write stories, estimate stories, and prioritize stories.

Chapter 9. How do you plan an iteration?……..115
Iteration planning can be thought of as a board game.

Chapter 10. Customer, Programmer, Manager:
What’s a typical day?
………………..125
Customer: questions, tests, and steering;
Programmer: testing, coding, and refactoring; [without cube]
Manager: project manager, tracker, and coach.

 
Chapter 11. Conclusion………………………………………..143

Chapter 12. Annotated Bibliography………………….145

Speech: Metaphors for Extreme Programming (XP)

William C. Wake, William.Wake@acm.org, http://www.xp123.com

Speech presented to the XP 2002 Conference, Sardinia, Italy, May 29, 2002.

Introduction

Grazie. Thank you for your kind invitation and welcome. It’s a treat to visit such a beautiful location as Sardinia.

I’m here today to share a few metaphors for Extreme Programming. In Kent Beck’s list of 12 practices for XP, he includes the system metaphor, where we try to create an effective and evocative vocabulary and way of thinking about our system. This talk isn’t about that; rather, I want metaphors for XP itself.

It’s been said you must experience XP to understand it. But I think metaphors and games can give us a helpful taste of what we’re trying to understand.

I have several goals:

  • I want to encourage creative, fun thinking in and around XP.
  • I hope at least one example makes you say, "I hadn’t thought of that – I’ll give it a try."
  • I hope some of these metaphors can help explain XP to non-practitioners.

Some of my analogies are for all of XP, some are for the major "12" practices of XP, and some are for minor practices that some teams use.

We’ll start with what I think of as the "individual skills" in XP: test-first and refactoring.

1. Test-First Programming is a Math Book

Test-first, or test-driven development, is one of XP’s fundamental design techniques. It works like this: 1. Write a test, which probably can’t even compile because you haven’t written any real code yet. 2. Implement a stub of the feature, so the test runs but fails. 3. Complete the feature so the test passes.

Many math books have the answers to odd-numbered problems in the back of the book. They do this because, paradoxically, you don’t solve math book problems to get the answer. Rather, you solve them to learn the techniques for solving similar problems.

Test-first is like this: first you have the right answer – the test. Your challenge is to write the code that provides the answer. Usually, if your code is wrong, your test will detect that.

The fun part is, you act as both textbook author and student. The author chooses a problem at just the right of level of difficulty, just as you must do for your test.

So, test-first is like a math book.

2. Refactoring is Compression

Refactoring is the code transformation technique XP programmers use to reduce duplication and improve how well the code communicates. We strive to say things "once and only once."

Think of a balloon. (I’m picturing one of those Mickey Mouse ones with the ears.) If you let out all the air, it can compress to take a lot less space, but you can easily restore it to its intended shape.

The way most file compression programs work is to keep track of words and phrases that have already been seen, and refer to the previous example rather than repeating the whole thing again. Since the reference is shorter than the original, the compressed file takes less space.

Refactoring is like that: by pulling out the common pieces and reducing duplication, refactoring makes programs conceptually smaller. Just as a compressed file reduces redundancy, we want the same for our code.

3. Collective Code Ownership is a Situation Room

Now we’ll move on to some of XP’s team practices.

Collective ownership is the practice of saying that the whole team owns the code jointly, so any pair can improve any part at any time.

I’ve become a fan of a TV show called West Wing. It’s a fictional show about the US president. About every four episodes, there’s a crisis, and a team gathers in the situation room. (These are also known as war rooms or strategy rooms.) The room acts as a command center: a place set apart, where all the experts gather to pool every bit of relevant information.

Collective ownership is like this. In a complex problem, we want all information in front of all the experts. No one knows all the answers, and one person’s partial solution may be the trigger for someone else’s full solution. By sharing the code, the team lets it become the home of the best picture it has.

4. Pairing is a Musical Duet, or Tag-Team Wrestling

Pair programming is the practice of having two programmers work together actively, sharing the keyboard and screen.

There’s a special type of piano music: two musicians, one keyboard, and four hands. Sometimes one person plays, then the other, but usually it’s both, with the melody shifting between players. Pairing is like this: the focus actively shifts between the players.

Then there’s tag-team wrestling. I can’t claim to be a fan, but my grandfather watched it every Saturday. Tag-team works like this: there are two teams of two wrestlers each. Let’s put Hulk Hogan and Jessie the Body Ventura on one side, and Stone Cold Steve Austin and the Rock on the other – sort of the geezers vs. the new ones. One wrestler on each team gets into the ring, and they start wrestling. At any time, usually if he’s in trouble, a wrestler can "tag" or touch his partner. Then he gets out, and the partner comes in. And of course, with wrestling as it is, sometimes both wrestlers on one team get in the ring at the same time, or even a whole ‘nother group of people gets involved.

Pairing is like this. When we get tired, or think our partner can do better, we pass the keyboard. Sometimes our partner takes it from us. And occasionally others get involved. Just like for tag-team wrestling, pairing is boring if nobody ever "tags." For the most benefit, keep the pair moving, and change partners often.

5. Iteration is a Clock Escapement

An iteration is a window of time where the team works on the highest-priority stories. Usually XP iterations are set between one and three weeks.

I don’t know if you’ve ever had a chance to look inside a clock – not an electronic one, but a mechanical clock such as a cuckoo clock. One part is the pendulum. Since a pendulum’s period is determined by its length, we can create a pendulum with a period of one second. Then we can move the minute hand one click for every 60 seconds.

Another part is the dial. Picture a spool, with a string wrapped around it and a weight on the end. If we put the spool on an axle and let go, the weight unwinds the spool in a second or so, spinning the dial too quickly. Somehow we have to prevent this.

There’s a third part called an escapement. Picture an object in the shape of an upside-down U, attached to the top of the pendulum. Imagine gear pegs on the back of our spool. When the pendulum moves to one side, the left arm of the escapement grabs a gear tooth and keeps the weight from unwinding it; we get a "tick." Then the pendulum moves to the other side and the dial moves slightly, but the other arm of the escapement grabs another tooth; you hear a "tock." (I’ll forgo my demonstration of how the cuckoo part works.)

There’s a saying: "Time is Mother Nature’s Way of keeping everything from happening at once." And that’s what iterations do. The weight of a customer’s needs make them want everything at once. But development doesn’t work that way – it’s only at the last moment that a team can deliver everything. Iterations let the team deliver the most important thing "this minute," first.

6. Learning XP is Learning a Foreign Language

Learning XP involves learning new skills for most people.

So, let me teach you a new language, courtesy of Virginia Satir. This language is just like your native language with one exception: whenever you say a verb, or action word, you have to repeat a synonym of the verb. (You can’t say the same one twice.) For example, I might say "For breakfast, I ate chewed a donut." So "ate" is the verb, and then I followed it with "chewed," which means nearly the same thing.

Let me put you, the audience, to work. Introduce yourself to your neighbor. Then in this new language (based on your native language), describe what you did yesterday. Don’t worry if your partner doesn’t have the same language. I’ll give you a minute or so, then call "switch."

OK – what was it like? [Clumsy, confusing, repetitive, self-conscious, …]

For me, using my little bit of Italian is like that. I’ve never had occasion to learn it before. What I’m finding is that when someone asks me a question I understand in Italian, I answer… in French. (This happens even when I know how to say the answer in Italian.) We go through those stages of conscious incompetence, to conscious competence, to unconscious competence.

XP is a new language. When you start, you’ll realize you aren’t doing test-first or integration or other things often enough. (A coach can help hear, reminding you of your intent.) You can get a flavor of XP in a day or a week, but it can take months to get into the groove, and many of us are still learning after years.

7. Continuous Integration is Balancing a Checkbook

Continuous integration is the practice of building and testing the system many times per day.

When you have a checking account, you write checks, and then once a month your bank sends you a statement. You "balance" it by comparing the bank’s statement against your checkbook, so you can discover transactions you’ve made that the bank doesn’t yet know about, and transactions the bank has made that you weren’t aware of.

You could balance your checkbook once a year, but it’s going to be hard, because there are many transactions to deal with, and an unresolved conflict can mess up everything following it.

Continuous integration is like balancing your checkbook often. By not waiting too long, you keep the number of "your changes" and "their changes" low, making it easier to figure out what’s going on.

8. Going Home Clean is Day Trading

"Going home clean" is the idea that at the end of the day, you will either check in your latest work, or throw it away, so you can go home with nothing checked out. Not every team uses this, but I recommend it as part of continuous integration.

The stock market has different kinds of investors. One type trades at a slow pace, keeping a stock for months or years. There’s another type of investor: the day trader. They’re the ones plugged into the news, trying to find the weather forecast in Colombia so they can bet for or against the coffee companies. If they buy 100K shares, and the price goes up one euro before they sell, they’ve had a very good day. Day traders buy and sell large amounts of stock and options, hoping to make money on small changes.

Lots of people lose money at this, and some make money, but they all have a firm rule: "Don’t leave your positions open overnight." They’ll sell everything they hold at the end of each day, even if it will generate a loss for the day. Why? Because too much can change while they’re not looking.

"Go home clean" (or "clean your plate") is the XP equivalent. It forces you to keep changes small, and know where you are on the day’s work. It reminds you that sessions longer than a day are too big.

I’ve seen people check out files for three days while they do a massive refactoring. Then integration is very tough, because the team isn’t idle during that time: they’re making lots of changes too.

So "go home clean" and "don’t leave your positions open overnight."

9. A Standup Meeting is a Starter’s Gun

The standup meeting is a practice borrowed from the Scrum process. The team stands, and each person briefly reports what they did yesterday, what they plan to do today, and what’s in their way. Not every XP team uses this.

Well, 25 years, and 50 kilograms ago, I ran track. Before a race, the runners do a little warmup running and a few practice starts, but they’re not starting to race yet. When it’s time, the starter says, "On your mark, get set, go!" and everybody starts running full speed, at the same time and in the same direction.

A morning standup meeting feels like that to me. Without a meeting, people trickle in; some people hear things and others don’t. With a standup meeting, we get everybody together at the same time, pointed in the same direction, and the day’s race begins in earnest.

Please consider adding this to your team, if you don’t use it already.

10. An Iteration Retrospective is a Game Film

A retrospective is a meeting or activity where the team looks back on how it’s done over the last iteration or more, and how it wants to behave going forward.

A sports team can improve by watching films of their games (and of their opponents). A player can see good and bad things: "When I move left, you’re always where I want you; and I see I’m dropping my shoulder at the wrong time."

A good software team looks back as well. Just like the sports player, we can make resolutions about how we’ll act in the future. ("Let’s try writing the acceptance tests first" or "Let’s try this standup meeting thing for a couple weeks.") The retrospective can be a tool to help a team adjust and refine its process.

11. Going XP is Like Goldratt’s Hike

Let me close by returning to a challenging problem: moving to XP. (Don’t worry, I won’t put you to work this time.)

There’s a great book called "The Goal" by Eliyahu Goldratt. It’s an unusual book – a combination love story and treatise on manufacturing. In this book, the main character goes on a hike with a scout troop. As the hike goes on, the troop spreads out – there’s a big distance between the front and back of the line.

The protagonist has a key insight: the group reaches its destination not when the first person gets there, but when the last one does.

It’s like this for a team moving to XP or otherwise changing its process. While there are some individual skills, XP is a team sport and a social discipline, and most practices require the team to cooperate. For these, it’s not the first person that matters, it’s the last. Even if you integrate 25 times a day, the team is not continuously integrating. It’s the same for the coding standard and many other practices.

So, as you improve your process, understand the limiting factors, and help your team move to an agreement about how to work together effectively.

Conclusion

Let me remind you of the metaphors we used:

  • Test-first is a math book
  • Refactoring is compression
  • Collective ownership is a situation room
  • Pairing is a musical duet, or tag-team wrestling
  • Iteration is a clock escapement
  • Learning XP is learning a foreign language
  • Continuous integration is balancing a checkbook
  • "Go home clean" is day trading
  • A standup meeting is a starter’s gun
  • A retrospective is a game film
  • Going XP is a group hike

I hope these have been interesting and useful, and I hope they inspire at least one improvement in how you work. Good luck on your hike.

Thank you.

Bill Wake is a software consultant and coach. He’s the author of Extreme Programming Explored, and the XPlorations articles at www.xp123.com. He is working on a Refactoring Workbook and an Extreme Programming Starter Kit. You can contact him at <William.Wake@acm.org>.

Copyright 2002, William C. Wake.

[Written May, 2002.]

Metaforma Brainstorming Tool

Goal: Brainstorm system metaphors.

Time: 10-60 minutes.

Introduction:
Introduce the idea of the system metaphor – “a story that everyone
can tell about the system.” A metaphor is also a “system of names”
that work together to support subtle expectations about how the
system works. In this exercise, people will lay out cards that
suggest metaphors, and explain them in the context of the system at
hand.

Material:

  • Standard deck of playing cards
  • Metaforma idea chart
  • Somewhere to record ideas

Play:
Select a dealer, who shuffles the deck and lays out five cards
face-up. For each card, the dealer will look it up in the chart,
and create a story about how it relates to the system. Once the
dealer has made an interpretation, the rest of the team is free to
brainstorm further.

First card:  What the system is.
Second card:  What the system is not.
Third card:  What the system could be.
Fourth card:  What the system’s environment is.
Fifth card:  What the system could be.

 

Once the team has explained its five cards, it’s free to
brainstorm further, inventing and combining ideas.

After the brainstorming is over, do a short evaluation session
to pick a “winner.”

Brainstorming Rules

  • Quantity, not quality
  • Let everyone participate
  • Wild ideas are welcome
  • Criticize later
  • Piggyback on others’ ideas

Metaforma Idea Chart
  Clubs Diamonds Hearts Spades
A spreadsheet alarm tour key ring
2 outline toolbox book graph
3 word processor engine movie breadboard
4 transparencies dashboard blackboard adapter
5 heartbeat office map plumbing
6 EKG roulette wheel tape recorder mask
7 concierge dice file card money sorter
8 tutor clock remote control passport
9 subcontractor calendar music score experiment
10 weather station radio mail planner
J assembly line cooking shopping mining
Q auction voting magazine agent
K double-entry  bookkeeping seeing a doctor building a  house interlocking  bricks

Joker – Say the first thing you think
of.

Source:
William C. Wake, December, 2001.
 

The System Metaphor

What is the system metaphor and how do you use it? We'll explore the definition and purpose, and discuss a few metaphors used in some XP projects. We'll explore possible metaphors for two types of systems. Finally, we'll discuss some of the limits of metaphors.

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.

We seek a system metaphor for several reasons:

  • 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.

Choosing a metaphor takes work. Your team will want to explore several possibilities, looking at the system through their world-views. If the best metaphor is a combination of two, that's OK.

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

Suppose we need to develop an application to support customer service representatives. For example: a customer calls in to complain that long distance doesn't work on their phone. The rep takes some information from them, and ensures that a technician works on the problem.

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

Editors have used a number of metaphors and models over the years.

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

It can be hard to find the right metaphor. There are several potential problems:

  • 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

We've briefly explored the meaning and usage of the system metaphor in XP.

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

[April 15, 2000]