ch01.qxd 1/21/02 3:00 PM Page 1
XP is a fluid process in which activities are no longer measured
in days or months but in seconds, minutes, or hours.
The game of XP is a productive one. It is exciting, fun, and challenging.
The important elements of the game are its principles, practices, and
players. Winning the game means delivering a product and having fun
while doing it.
XP requires the heavy use of gray matter. Many of the logical areas of
the brain will be tapped. When we conceptualize, we use the abstract
thinking part of the brain. Planning uses our strategic thinking. Develop-
ment calls upon our creative areas. We celebrate our deliveries with ac-
tivities that rest our brain and rejuvenate our soul.
Like thought, each of these aspects of XP can be completed in a split
second. We can think of a new user story, mentally put it into our plan,
create a new design, and mentally deliver the product in our mind, all in
between breaths. To be sure, making all of this happen in the product
takes a good deal longer.
XP is fluid. Each area (conceptualization, planning, development,
and delivery) is like a color in a kaleidoscope. As we move the handle
around, colors merge, and new colors emerge from the combination of
these basic ones. We do not have a waterfall view, but an organic one.
In other words, out of development may come conceptualization,
planning, adaptations of the development process, or delivery. You never
know what new things will come of our creativity. The game is fast paced,
so take hold of your XP values: communication, simplicity, feedback, and
most of all, courage. Here we go!
ch01.qxd 1/21/02 3:00 PM Page 2
ch01.qxd 1/21/02 3:00 PM Page 3
The practices of Extreme Programming are
designed to work together to provide more
value than each one could individually.
W e will explore the activities of XP in the coming chap-
ters. Before we do, however, we should mention the
principles that codify XP. Understanding these principles
is important to obtaining an understanding of the forces
that drive XP. Some of these principles are simple com-
mon sense. Others will quickly become the basis of most
future software development processes.
Perhaps the most extreme of the XP principles is its insis-
tence on having a real customer working directly with the
project. This person should be one of the eventual users Your
of the system. They should also be able to represent the Customers
needs of their fellow users.
ch01.qxd 1/21/02 3:00 PM Page 4
Our customer must be empowered to answer ques-
tions and make decisions regarding feature priority, risks,
and so forth. They will take part in planning by writing and
prioritizing stories and deciding release content. By having
them work along with the development team, they get to
provide constant feedback, as well as answer any ques-
tions the team may have regarding what they really meant
when they wrote the stories.
The customer is also responsible for writing the ac-
ceptance tests (see Chapter 5) that verify that each story is
implemented correctly (that is, has the desired behavior).
Customers are generally not software developers, so they
will need help from the team if the acceptance tests are to
be automated (which is strongly suggested).
A metaphor is a powerful way to relate a difficult idea in an
Use unfamiliar area. Every XP project should use one or more
Metaphors metaphors to guide it and to provide a shared context. By
to Describe having a shared metaphor, everyone involved shares an
Difficult understanding of the big picture view of the system and the
Concepts problem that it is to solve. This gives a conceptual frame-
work in which to talk and a source for terminology. The
metaphor also serves as a definition of the overall concep-
tual architecture of the system.
Note that the metaphor may be a simplistic represen-
tation of a concept or feature. Metaphors are not meant to
be accurate in every respect. Rather, they provide a context
for discussing problems and their solution.
Here’s a quote from the Chrysler Comprehensive Com-
pensation project regarding the use of metaphors [Garzaniti
“Chrysler is a manufacturing company; we make cars.
Using a manufacturing metaphor to define the project
was an important first step in getting the team (and
management) on a level playing field. The concepts of
lines, parts, bins, jobs, and stations are metaphors un-
derstood throughout the company. The team had the
benefit of a very rich domain model developed by mem-
Practical Guide to bers of the team in the project’s first iteration. It gave
eXtreme Programming the members of the project an edge in understanding an
extremely complex domain.’’
ch01.qxd 1/21/02 3:00 PM Page 5
This example metaphor uses the elements of an as-
sembly line to describe posting rules in a payroll applica-
tion. Posting rules specify the way that accounts are
debited and credited when creating paychecks. Like parts
from a set of bins on the assembly line, money is taken out
of each account (expense reports, salary, and bonuses),
and a paycheck is written. Unlike an assembly line, how-
ever, the paycheck may be debited so the money is moved
back into accounts (such as a medical plan or 401K).
Metaphors are especially useful when developers from one
domain are asked to work on a project that falls in another.
Software development projects of any significant size have
to be planned. Planning serves to provide a mutual under-
standing to all parties of approximately how long the proj-
ect will take. It also serves as a bellwether of the size of the
project versus the capability of the organization. Is it larger
than the capability of the team? Approximately how long
will it take the team to complete? You need to have some
direction and shared understanding.
Planning does not mean that you spend six months or
more doing a detailed analysis and a week-by-week plan
for the next five years. However, you do have to do some
minimal planning to know where you are going, roughly
how you will get there, and what risks might be encoun-
tered along the way.
You must understand one thing about your plan (and
there’s no escaping this). It is inaccurate, and it will change
as you learn more, as requirements change, and as new risks
are discovered. In fact, the farther in the future that some-
thing is planned the more likely it is to be inaccurate and the
greater the inaccuracy is likely to be. It is simply too difficult
to predict too far into the future. By the time you get there,
chances are, your plan will be totally unfounded in reality.
However, you must do some planning. The next ques-
tion is who gets to make the planning decisions? The an-
swer is those who know. That means that the customer
gets to make decisions about the business and the busi-
ness problems that the project is aiming to solve, and the
development team gets to make decisions about technical
issues. Kent Beck breaks it down as follows [Beck 2000]: 5
ch01.qxd 1/21/02 3:00 PM Page 6
• Business people get to decide the following:
• Scope—What does the system have to do?
• Priority—What pieces are more important?
When the scope turns out to be too big, what
gets dropped or deferred?
• Release contents—What makes up each release?
• Release dates—When do we deploy releases?
These can be driven by marketing concerns.
• Technical people get to decide the following:
• Estimates—How long will it take to implement
• Consequences—What are the implications of
making a particular decision? These are the
technical results from certain decisions, such
as tools, hardware, subsystems, and so forth.
• Process—How will we build the system? This
refers to team organization, culture, facilities,
and so forth.
• Detailed scheduling—When will a task be com-
pleted? This is the scheduling within a release.
Often, the riskiest things are tackled first to
minimize the overall risk.
Meetings. Most developers hate them because they are
Keep often long, drawn-out, and boring affairs that keep you
Meetings from the code. Meetings are invaluable as a communica-
Short tion forum, though, but only as long as they are short and
focused. To this end, XP uses standup meetings. The con-
cept is a simple one: No chairs allowed. If everyone has to
stand, it ensures that the meeting will be quick and to the
The best time for a standup meeting is daily, early in
the morning after everyone has shown up for the day. Get
the team in a circle with the caffeinated beverage of their
choice in hand.1 Go around the circle and have each team
member give a brief status update: what they did yester-
Practical Guide to day, what they’ll be doing today, and any issues or an-
eXtreme Programming nouncements that the team should be made aware of.
6 1Don’t underestimate the value of this in keeping meetings short.
ch01.qxd 1/21/02 3:00 PM Page 7
Keep the meeting focused. Don’t let discussions start
up. If people need to talk, they can meet up later in the
Testing is another core piece of XP philosophy. Testing oc-
curs on multiple levels. The first level is the unit tests,
written by the software developers. Unit tests are written
before the code that runs them. A unit test asserts that a
small piece of functionality works as expected. You can’t
consider a task completed unless there is a comprehensive
set of unit tests for it. An implication of this is that you
can’t integrate functionality until all of its unit test cases
are written and have passed.
In fact, we strive to write the unit tests first, and then
implement the feature to make the test pass: test, code,
test, code, and so on. Several advantages can be gained by
adopting a test-first approach to development:
• Tests provide a definition or documentation of
the desired behavior.
• You know when you have the functionality fully
and correctly implemented. When the test passes,
you can say confidently, “Done... next!”
Too much code is deployed without being thoroughly
tested with the idea that you’ll get bug reports informing
you of the problems that really occur. However, that’s an
expensive and unstable way to go. Part of the reason
(based on personal experience) is that it’s a real drag to
write test code after putting in a stellar performance writ-
ing the problem-solving code. That’s another reason to
adopt a write-the-test-first approach to coding. The test
then becomes part of the solution. You have to spec the
behavior anyway, either on paper or in your head, so just
write it down using the syntax of the language you’re cod-
ing in. Also, working this way means that you never have to
spend any great amount of time writing only test code.
You write a little bit of test code and then write some pro-
duction code. You alternate between these two activities
until the task is completed.
ch01.qxd 1/21/02 3:00 PM Page 8
What do you test? The simple answer is everything that
could possibly break. That makes it easy, right? Maybe it’s bet-
ter to think of it as don’t test things that could not possibly break.
What might that be, you ask? Accessors and mutators
(otherwise known as getters and setters) are a good exam-
ple. There’s no way that returning or setting an instance
variable can go astray. Simple creation constructors2 are
another class of things that can be safely ignored. On the
other hand, when you are just starting out using test-first
development, it might help to test these simple things just
to get into the groove of this style of development.
You should understand one more thing about tests.
They have to run at a 100 percent pass rate in the produc-
tion code. This lets you integrate with confidence and
know that, if a test fails during integration, your newly
added code is to blame. The test that failed will point you
to the culprit.
Having this comprehensive collection of tests gives
you a great feeling of confidence. This confidence lets you
be aggressive because, if you break anything, you’ll know
the next time that you run the tests.
Speaking of running the tests, when and how often
should you run them? You should run them as often as
you can. This implies that tests should be fast and light-
weight. Ideally, you should run them (at least those for the
subsystem you’re working in) each time that you success-
fully compile. At the very least, you should run them (all of
them preferably) before and after you make any changes.
Running them before gives you confidence that you have a
stable platform to work on, and running them after proves
that you didn’t break anything.
“Keep it simple” are words to live by. They are words to de-
Keep it sign by, too. Being extreme, XP keeps the design as simple
Simple as possible. There are several things at play here:
• Design for today.
Practical Guide to • Do the simplest thing that could possibly work.
2A creation constructor is a constructor that takes a set of parameters and
8 simply assigns their values to instance variables with no computation.
ch01.qxd 1/21/02 3:00 PM Page 9
• Continuously simplify the design.
If we keep the design simple and clean, it stays nimble
and malleable. By deferring design until it is required, we
can get something valuable working now. We call this “just
in time design.” This flies in the face of conventional prac-
tices that prescribe generalized design. Generalized design
pushes making your design flexible enough to handle to-
morrow’s requirements. Why not wait until you need it be-
fore designing for it? There’s a good chance that you won’t
need what you think you will and an even larger chance
that you’ll need something completely unanticipated.
By continually revisiting the design, you can keep it
simple and flexible. One major criticism leveled against XP
is that “You guys don’t do design.” This isn’t true. XPers don’t
do big up-front design, but we are doing design all the
time, continuously [Fowler 2001A].
Just what is a simple design? In order of increasing im-
portance, a simple design [Beck 2000] includes the following:
• Runs all the tests (This is pretty obvious.)
• Reveals all the intention (The design is clear and un-
• Involves no duplication (This is obvious. Watch for
• Contains fewest number of classes or methods
(Again, this is obvious.)
Robert Martin’s advice on design simplicity is to not get
too hung up about it [Newkirk 2001]. It is more important to
be willing and able to refactor as the opportunity and the
need present themselves than to get it one hundred percent
right, sparkling clean, and as simple as possible the first time.
Two heads are better than one, but, in XP, two heads to-
gether are better than two separately. In XP, people develop
in pairs. Every line of production code is written by a pair of in Pairs
developers. The driver has control of the keyboard and mouse,
and the partner watches and helps. The driver is actively writ- Extreme Principles
ing tests, coding, integrating, or refactoring. The partner 9
ch01.qxd 1/21/02 3:00 PM Page 10
watches, keeping in mind strategic goals; catching spelling
and syntax mistakes; and offering insight, ideas, and sug-
gestions. The partner can see the forest while the driver sees
the trees. This puts the partner in a great position to be able
to see when things are swerving off track or getting too gen-
eralized. The partner can also be thinking about other tests
that could be written. If the partner has an idea of how
something can be implemented, the pair can swap roles.
The general way to initiate role swapping are two phrases:
“Here, you drive,” and “Can I drive?”
To support working together effectively, you should adopt
Code to a teamwide set of coding standards. All team members
Standards should voluntarily agree to adhere to them. It doesn’t mat-
Practical Guide to ter what they are, as long as they are used consistently. It’s
eXtreme Programming generally best to use some common standards. For exam-
ch01.qxd 1/21/02 3:00 PM Page 11
ple, if you are working in Java, use the standards from Sun
Microsystems [JavaConv 1999];3 for Smalltalk, use Smalltalk
with Style [Skublics 1996].
If you have consistent standards, other practices such
as the following work:
• You can pair program because both partners work
in the same format.
• Anyone could own the code because you all write
it in the same style.
• You can refactor because you understand the for-
mat of the code that you are changing and others
will understand the format of your work.
• Finally, you can go at full speed because you don’t
need to reformat code as you go, or be constantly
having to switch from one style to another, or be
trying to understand the formatting and style as
well as the code itself.
Traditional software development either assigns owner-
ship of classes to specific team members or requires a de-
veloper to get an exclusive write lock on any classes that Collectively
they will be modifying. Both practices create problems.
Let’s look at each practice in turn.
When developers own classes, anyone that needs a
change made to a class that somebody else owns has to
request that change of the class owner. Eventually, they
have to wait until the owner has time and/or gets around
to it. Alternatively, they make their own local changes and
submit them to the class owner. Both of these approaches
create problems. To compound matters, let’s say that they
request the required change (which, by the way, may not
be quite right the first time), get tired of waiting, and make
a local change to the class. Eventually, the class owner
makes the change. Now, there are parallel changes: one
that is official (made by the class owner) and one that
works (made by the developer who needs it and knows
best what it has to do).
3An alternate source of standards is [Vermeulen 2000].
ch01.qxd 1/21/02 3:00 PM Page 12
We would like to revisit the idea of class ownership by
individual developers for a minute. Class ownership tends
to create specialized knowledge in the development team.
Joe over there knows the communications subsystem,
Mary knows the Graphical User Interface (GUI) compo-
nents, and so forth. Few people have any deep knowledge
of the entire system, other than at an Application Pro-
gramming Interface (API) level. What happens if Joe gets
an offer that he can’t refuse? His specialized knowledge
goes with him. A less devastating situation might be if
Mary goes to a conference for a week or on vacation. Does
GUI related development stop?
Let us remove the class owners but keep the source
control tools that provide that level of functionality. Now
you can make changes to anything, but have to get a write
lock first. This leads to problems as well. You can make the
change, but, if another developer has a lock on that file,
you have to wait for them to finish working and to release
the lock. Most source control tools let you know who has
write locks, so at least you know who to whine at. However,
this causes bottlenecks and delays, either due to waiting
for access to a class or due to the time required to inte-
grate local changes into a newly released version.
XP prescribes team ownership of everything. If a
change needs to be made (either to add functionality or to
improve the design), the person who is in the best situa-
tion to make it (that is, the developer who sees the imme-
diate need for the change) can.
A good source control system is a must in order to make
collective ownership work. Exclusive write locks don’t work.
Every developer must be able to modify anything at any
time. You can’t have people waiting for write access.
A modern configuration management tool goes a long
way to making collective ownership work. To really make
this work, you have to be doing continuous integration as
well. That way, if there are conflicts, they will be small and
will be discovered as soon as possible (remember that you
should be integrating at least daily).
Practical Guide to
ch01.qxd 1/21/02 3:00 PM Page 13
In order to be working aggressively at full speed, you need to
be integrating your work into the production codebase con- Integrate
tinuously. At the very least, you should be integrating daily. Continuously
Ideally, it should be more often. You should integrate after
each task you complete. The tests allow you to know with
confidence that, if all (for the entire system) run success-
fully, you can release the new version of the codebase. By in-
tegrating this frequently, the chance of your changes
conflicting with someone else’s is minimized. If there is still
a conflict, it will be minimal. These short integration cycles
also keep everyone converging. The system doesn’t have
time to diverge between integrations.
What is refactoring? According to Martin Fowler [Fowler
1999], it is the following:
“Refactoring is the process of changing a software sys-
tem in such a way that it does not alter the external be-
havior of the code, yet improves its internal structure. It
is a disciplined way to clean up code that minimizes the
chances of introducing bugs.”
There are many simple refactorings as well as several
complex ones. Go read Martin Fowler’s wonderful book
[Fowler 1999] for a catalog of refactorings, as well as dis-
cussions of other related issues.
You should be refactoring all the time. When you are writ-
ing tests, you may want to refactor to make something easier
to test. When you are coding some functionality, you may
want to refactor to make it easier to add or to remove dupli-
cation. Another great way to use refactoring is to take existing
code and restructure it so it conforms to a design pattern.
According to Ron Jeffries [Jeffries 2001A] the following
“There are two moments when one considers refactoring
as part of doing a task: before the task begins, to “make
a space” for the new code, after the task is implemented,
to make the new code and old code as clear and simple
ch01.qxd 1/21/02 3:00 PM Page 14
“Release early; release often.” “Frequent, tangible, and working re-
Release sults.” These are two phrases that sum up the idea of using
in Small small releases. A small release is between one and several
Increments months worth of work. Six months is generally too much.
By having small releases, you get new functionality into
the hands of real users as early as possible.4 This provides
you with invaluable feedback on whether you’re headed in
the right direction. It also catches any defects as early as
Having small releases lets you plan more accurately as
well. The further into the future that you try to plan means
the more inaccurate you will be. Planning a couple months
in advance makes much more sense than trying to plan six
months or a year ahead.
Just don’t forget that a release has to be complete and
make sense. Releasing with a feature half implemented
isn’t of much use to anyone. The rule in an XP shop is that
it’s not considered shippable until it is completely fin-
ished. Remember, as well, that release dates are some-
times influenced by external factors. For example,
marketing may want a release with support for the latest
feature in time for a large industry conference. Sales may
need to have online order taking live in time for the Christ-
mas shopping season.
Nobody does their best work when they are stressed,
Don’t Burn under pressure, and overtired. It’s funny that those exact
Out (40-Hour conditions are so prevalent in our industry. If you do XP,
Work Week) stress and pressure will be dealt with by the planning prac-
tices. It’s easy to prevent people from becoming overtired.
Send them home after eight hours. Encourage a reason-
able amount of playtime at work. This is also a great stress
buster and keeps everyone relaxed and in top form. The
40-hour week and 8-hour day are conceptual. The idea is
not to work longer than works for you.
4Getting functionality into your users’ hands does not necessarily mean de-
Practical Guide to ployment. There are often business reasons for deploying systems less fre-
quently. However, frequent user feedback is essential to the XP way of creating
eXtreme Programming software.
ch01.qxd 1/21/02 3:00 PM Page 15
Changing requirements are a given in the rapidly evolving
business environment in which we all work. If we are adap- Embrace
tive, change is beneficial. It sneaks up on our competitors Change
and bites them on the bottom. If we embrace change, it
works to our advantage. The key concept for a successful
XP project is to help the customer and development teams
understand that change is the norm. We never know every-
thing up front whether we belong to the customer team or
the development team.
Traditional approaches to change in requirements sug-
gest that we can make predictions and freeze the require-
ments accordingly. Requirements documents commonly
view the world as capable of turning change on and off in
discrete intervals. In the real world, change happens con-
The XP solution is simple: Stay flexible. Do the Zen
thing, and be like water, adjusting your course as required.
Rigid projects break and get canceled. Flexible projects
bend with the wind (OK, no more Zen), accepting changes
rather than ignoring or fighting them. By assuming that not
everything is right or known up front, an XP team can accept
changes with little or no pain. Remember short iterations,
release early and often, and to keep the customer in the
loop. These practices give the team invaluable feedback as
to where they are and where they are going, and, most im-
portant, where they have gone off course. Feedback like that
is used to make adjustments to the plan. Keeping the code
clean and simple ensures the code is also flexible and al-
lows it to bend when confronted by changing requirements.
ch01.qxd 1/21/02 3:00 PM Page 16