Home > Store

Extreme Programming Explored

Register your product to gain access to bonus material or receive a coupon.

Extreme Programming Explored


  • Sorry, this book is no longer in print.
Not for Sale


  • Copyright 2002
  • Dimensions: 7-3/8" x 9-1/4"
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-73397-8
  • ISBN-13: 978-0-201-73397-6

You know what XP is, how to get it up and running, and how to plan projects using it. Now it's time to expand your use of Extreme Programming and learn the best practices of this popular discipline.

In Extreme Programming Explored, you can read about best practices as learned from the concrete experience of successful XP developers. Author and programmer Bill Wake provides answers to practical questions about XP implementation. Using hands-on examples--including code samples written in the Java programming language--this book demonstrates the day-to-day mechanics of working on an XP team and shows well-defined methods for carrying out a successful XP project.

The book is divided into three parts:

  • Part 1, Programming--programming incrementally, test-first, and refactoring.
  • Part 2, Team Practices--code ownership, integration, overtime, and pair programming; how XP approaches system architecture; and how a system metaphor shapes a common vision, a shared vocabulary, and the architecture.
  • Part 3, Processes--how to write stories to plan a release; how to plan iterations; and the activities in a typical day for the customer, the programmer, and the manager of an XP project.

To demonstrate how an XP team uses frequent testing, you'll learn how to develop the core of a library search system by unit testing in small increments. To show how to make code ready for major design changes, the author teaches you how to refactor a Java program that generates a Web page. To see how a system metaphor influences the shape of a system, you'll learn about the effects of different metaphors on customer service and word processing applications. To show how customers and programmers participate in release planning, the book demonstrates writing and estimating stories, and shows how the customer plans a release.


Sample Content

Online Sample Chapter

Extreme Programming for the Customer, Programmer, Manager: What's a Typical Day

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:

Table of Contents






1. How Do You Write a Program?

Program Incrementally and Test First.

2. What is Refactoring?

“Refactoring: Improving the Design of Existing Code.”—Martin Fowler.


3. What Are XP's Team Practices?

“We'll Explore These Practices and Their Alternatives.”

4. What is it Like to Program in Pairs?

Pair Programming is Exhausting but Productive.

5. Where's the Architecture?

Architecture Shows Up in Spikes, the Metaphor, the First Iteration, and Elsewhere.

6. What is the System Metaphor?

“The System Metaphor is a Story that Everyone—Customers, Programmers, and Managers—Can Tell About How the System Works,”—Kent Beck.


7. How Do You Plan a Release? What are Stories Like?

Write, Estimate, and Prioritize Stories.

8. How Do You Plan an Iteration?

Iteration Planning Can be Thought of as a Board Game.

9. Customer, Programmer, Manager: What is a Typical Day?

Customer: questions, tests, and steering.

Programmer: testing, coding, and refactoring.

Manager: Project Manager, Tracker, and Coach.

10. Conclusion.


Extreme Programming (XP) defines a process for developing software: it addresses the problem from early exploration through multiple deliveries. We'll explore XP from the inside to the outside.

First, XP is a programming discipline. We'll look at a core innovation: how "test-first" changes the programming process itself. We'll also discuss refactoring--the way XP programmers improve their code.

Second, XP is a team discipline that has developed practices that help produce a high-performing team. We'll compare XP to alternative practices and see XP's team practices in action.

Finally, XP is a discipline for working with customers. XP has specific processes for planning and daily activity. We'll see how a team might schedule a release or iteration and what the team does all day.

Why Read This Book?

If you've heard anything about XP, you probably have had questions about the mechanics or the purposes of various aspects of XP. I've tried to capture the questions I've had, along with answers I've found.

Several things about XP were surprises to me, particularly the tight cycle of test-first programming (only a couple minutes long), the use of a metaphor, and the starkness of the division of labor between customer and programmer. We'll look at these and many other topics.

You, the reader, may have several areas of interest that bring you to this book:

  • Java and object-oriented programming. The first section of the book uses Java programming language examples to focus on test-first programming and refactoring. Programmers may find the discussion of team practices useful as well, particularly the ideas about metaphors and simple design.
  • Extreme programming, from the perspectives of programmer, customer, and manager. We'll explore several areas more deeply or from a different perspective than the rest of the XP literature, especially the team-oriented practices, the metaphor, the planning process, and daily activities.
  • Software process in general. XP is one of several so-called agile, lightweight, adaptive processes that have been introduced in the last few years. By taking an in-depth look at XP's process, we can more clearly delineate where XP fits in with these related processes.
Who Is the Author? Why This Book?

I'm "just a programmer," with about 15 years of experience, about half in compiler development and the rest in library, telecom, and financial services.

I attended the first XP Immersion class in December 1999. Although I had read Extreme Programming Explained, and much of the XP material on the Web, I was surprised by how test-first programming really worked (a much quicker cycle than I'd expected).

The question of testing user interfaces came up in the class; Kent Beck said he didn't usually develop user interfaces test-first, but asked, "Could you?" That inspired me to write an essay on the topic.

I write to learn, so as I explored various XP topics, I wrote a series of articles I called "XPlorations" and made them available on the Web. With the encouragement of my peers, I've adapted some of those essays for this book in order to give a coherent view of the issues surrounding XP.

What Is the Philosophy of This Book?

Be concrete. Use real (or at least realistic) examples. When code appears, it is Java code.

Answer questions. Because most of the chapters originally were written as essays for myself as I learned or taught others, each chapter begins with a question and a short answer. Many chapters include a Q&A (question and answer) section as well.

Be focused. Make each chapter focus on one topic. Tie it to other chapters where possible.

Be precise but informal. I use "I," "we," and "you" a lot. For the most part, "you" is addressed to a programmer, but, in some sections, the word may be addressed to managers or customers.

Bring experiences to bear. I relate this material to real experiences.



Acceptance tests, xx, 119, 145
   graph, 137
   running of, by customers, 126
   tracking of, by trackers, 135, 137
   written by customers, 124, 125- 126, 130
"Anti-patterns," 27
Architecture, 75-83
   defined, 75
   documenting, 81
   Extreme Programming, xxiv
   first iteration, 76, 78-79, 83
   4+1 View Model, 75
   metaphor, 76, 77, 83, 86
   refactoring, 76, 80-81, 83
   small releases, 76, 80, 83
   spike, 76-77, 83
   team practices, 76, 81, 83
Array of lines model, 90
   refactoring, to convert to Vector, 14, 17
Assembly line metaphor
   customer service example, 88

Beck, Kent, xiv, xxiii, 4, 7, 27, 55, 78, 81, 85, 143
Beizer, Boris, 125
Berra, Yogi, 144
Black box, 48
   paired programming and nature of, 70
Broadcast metaphor, 92
   refactoring separated from, 32
Bugs, 82
Builds, daily, 52-53
Bullpen office type, 57
Bus number, 50

Capital One, 64, 70
Card metaphor, 90
Case sensitivity, 13
   and XP managers, 134
Chrysler 3C project, 139
   role of, in managing XP, 132, 138-140, 141
   See also Customers; Trackers
Cockburn, Alistair, 82, 138
   breaking, 53
   duplicate, 29, 140
   testable, 3
   unit test, 129. See also Refactoring
"Code freeze," 52
Code ownership, xxiii, 47, 48-52, 60
   collective, 50-52
   by layer ("tribalism"), 50
   monogamous, 48-49
   orphan, 48
   "serial monogamy" or "rental property," 49-50
   "tag," "musical chairs," or "trial by fire," 48
Code reviews, xxiv
   and paired programming, 70
Code smells, 27, 30, 31, 42, 43, 130
Coding standards, xxiii, 47, 59-60, 81, 129, 145
"Coding wars," 56
Collective code ownership, 50-52, 145
Combination metaphor, 91
   and first iteration, 79
Connection metaphor, 92
Contingent estimates, 121
Continuous integration, 53
Controls and gauges metaphor, 92
Coyne, Richard, 87
Cross-training, 82, 120
Crowd programming, 64
Cubicles, 56
Customers, xiii, xx
   acceptance tests written by, 130
   and Extreme Programming, xx, xxi-xxii
   future role of in XP, 145
   and paired programming, 65
   and planning game, xxiv
   questions and answers by/for, 127-128
   and release planning, 99
   and Release Planning Game, 100
   role of, during iteration, 123-128
   scope chosen by, 103
   stories selected for iteration by, 117, 122
   stories split by, 102
   stories written by, 101
   tasks of, during release planning, 135-136
   and XP managers, 133
   See also Coaches; Programmers; Trackers
Customer service example, 87-89

Daily builds, 52-53
   denormalization, 48
   model, 82
"Data bag" class 7
Data structures metaphor, 92, 93
DeMarco, Tom, 56
Deployment (technical) architecture, 81
Deployment view, 75
Design, xxiii, 5-7
   metaphors in, 87
   and paired programming, 70, 72
   in test-first programming, 129
   of tests, 125
Desktop metaphor, 87, 92
Disengaged programming, 64-65
"Do It" interface, 58, 79, 80
Domain objects, 6
"Do the Simplest Thing That Could Possibly Work" principle, 10
DRY ("Don't Repeat Yourself") principle, 30
Duplicate code, 29, 140
Dynamic objects metaphor, 92

   shopping carts for, 87
Editors example, 90-91
"Eight-hour burn," 54
Empty queries, 13
   customer service, 87-89
   editors, 90-91
   more metaphors, 91-93
   release planning: exploration, 104-113
   release planning: sorting and selecting, 113-114
Extract Method, 28, 31, 34, 35, 43
Extreme Programming, 26
   and architecture, 75-76
   and coding standard, 59, 60
   collective code ownership used by, 51-52
   description of, xiii, xix-xxii
   and 40-hour work week, 54-55, 131
   future of, 144-145
   getting started with, 145
   layered approach with, x
   limitations with, 83, 144
   open workspaces specified by, 56
   as processes, xxiv
   as programming, xxiii
   programming activities, 128
   resources, xxv
   rigidity and, 143
   small releases favored by, 58
   as team practices, xxiii-xxiv
   test/code cycle in, 8
   underlying values in, 144
   See also Team practices

Finseth, Craig, 90
Firewalls, 78, 79
First iteration, 76, 78-79, 80, 83
"4+1 View Model of Architecture, The" (Kruchten), 75
40-hour work week, 54, 55, 60, 131
   See also Workspaces
Fowler, Martin, 23, 27, 28, 32, 81, 130
   and first iteration, 79
   and XP managers, 132-133, 134

Gamma, Erich, 4
   and metaphor, 86
Geographically separate groups, 55-56
Getter tests, 7
Graphical user interfaces, 20, 58
   desktop metaphors for, 87
   test-first programming for, 16
GUIs. See Graphical user interfaces

Hardware, 133
   paired programming and nature of, 70-71
"Hello, world" program, 78-79
High-bandwidth communication
   effectiveness of, 143
Hill, Michael, 59, 78
Hosting meetings
   and XP managers, 134
Hunt, Andy, 30

"Ideal weeks"
   and story points, 102
Identity metaphor, 92, 93
Implementation view, 75
Incremental programming, 3
Information objects metaphor, 92
Integration, xxiii, 47, 60, 130, 133, 144
   continuous, 53
   daily builds, 52-53
   just before delivery, 52
   one-button, 79, 80
   See also Graphical user interfaces


Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership