In the June 1999 issue of CppReport
, JohnVlissides PatternHatching
is titled XP, and consists of an interview with KentBeck
...another contribution to WhosWritingAboutXp.
Well, it's been long enough since that article appeared that I'm now
free to include it here in its entirety. -- JohnVlissides
I came onto Wiki to find something else ... and I found this. Great
interview, thanks. And buried in the middle:
''So the metaphor doesn't have to be a single thing, but there has to
be a unifying story. Then from within the metaphor you can generate
class names, method names, and variable names that have unity.''
Can anyone explain further (give examples?) how to go from metaphor to
names in the program that have unity? I didn't realise that this was
(at least partly) what the whole XP metaphor thing was for
that I know that I would love to know more! -- RichardDrake
See SystemMetaphor and OOPSLA 97 paper (ExtremeArticle).
, June 1999
(c) 1999 by John Vlissides. All rights reserved.
I thought I'd take a break from the compound pattern theme and try
something completely different. Recently I picked up a copy of William
Zinsser's On Writing Well
, a wonderful little book on the
secrets of composing good nonfiction. After finishing the chapter on
writing interviews, I couldn't wait to do one. But who would be my
It wasn't long before I settled on Kent Beck, one of the original
patternmeisters and the father of something called Extreme
Programming, or XP for short. What follows is a good chunk of our
Let's start off with a cook's tour of what XP is and isn't.
Well, I was frustrated with what I saw from methodologies. I
had clients who tried to follow the advice of people who were writing
from the exponential cost curve perspective---people who tried to move
big decisions up front, people who assumed once you made those big
decisions you couldn't change them. And those clients were failing
There are lots of subtle ways in which that perspective plays. Take
reuse, for example. It's a big up-front decision. If you strive for
reuse, you're making design decisions early that you expect to hold
for the next five years; otherwise you can't reuse stuff. But in my
experience, you can't get reuse that way, unless you don't learn
anything during development.
There's that old adage about how you can't reuse what you
Yup. Then there were the clients whose development process
was total chaos---they just tried to program. Smalltalk let them
program faster---I call that the Smalltalk-as-more-rope
phenomenon---so they could get further with chaos. But it was still
chaos, and eventually they'd die.
So I have two kinds of clients, and neither are doing very well. I
knew there had to be another way.
The thing I liked about methodologies was a certain
discipline. There's global thinking in a methodology's rules. They
provide implicit big-picture context.
But if I have this programming environment, and it's extremely
flexible, and yet I'm doing everything I can to lose the flexibility
as soon as possible, then I'm just not getting the value out of it
that I could. So I had to find some middle ground between the
change-averse culture and the change-besotted culture of Smalltalk.
Right. You start with pure programming. Then you ask, What's
the least we could add to have a process that's predictable and stable
and productive, low-risk, responsive to business---and a lot of fun to
execute? Those are my goals.
XP says that if change is cheap, then we behave this other way.
That's the fundamental technical assumption. If change isn't
cheap---and sure, there are people for whom that's the case---then
they just shouldn't behave this way, because it's not going to work.
But if you can make change cheap, then you behave in a completely
different way. You act nearly like all you have to do is program.
Except that you have the PlanningGame
, where you give
business decision-making power to the businesspeople; and you keep
technical decision-making power in the technical part of the team (not
including the customers, who are part of the team too). And you have
unit tests. And you do refactoring and pair programming.
So you take good programming---the flexibility and responsiveness of a
really good programmer with really good tools---and add just enough to
retain its goodness along with the discipline that keeps things under
control and lets you estimate accurately over time. And you make sure
that the business can steer the project on a fine-grain level.
It sounds like there's a lot of learning by doing, feeling
your way, et cetera. If so, then how can XP apply to the company that
insists on a two-year plan, with headcount allocated up-front and
milestones set in Jell-O? Or is XP just not appropriate for that
XP is fine as long as everybody understands that that
mindset is a fiction. The higher you go in the management chain, the
more people understand that such plans are always---and had better
be---subject to change. Second-level managers are the most dangerous
here, because they think that if they don't execute the plan, they're
going to be in trouble. But if you go up to the CIO or CEO of a
Fortune 100 company, they know they'll have to make adjustments.
That's their job. They expect plans to change, and they look forward
to adding value when things have to change.
You can lay out two years' worth of development in the XP planning
stuff. You can say, "Here's what we can
do in the next two years given what we know today, the estimates we've
made, and the measurements of our productivity over the last n
months." Or, "Here's four years' worth of stuff; which two-years'
worth do you want?" And the businesspeople can say, "Well, if you can
do this two-years' worth in two years, it'll be worth it." And you
Now, in reality, when you execute that two-year plan, you're going to
go into production as quickly as possible---a matter of a few months,
six at the outside. The longer you go without being in production,
the more dangerous a project is. So you divide it up into smaller
releases: "Here's two years' worth. Now, businessperson, could you
please give us the important dates over the next six months?" Or,
"What's the smallest and most valuable part of this that lets us get
to a small release?"
Incremental releasing, incremental testing ... there's a lot
of incrementality here.
XP has four values: communication, simplicity, feedback, and
courage. If you're on an XP team, and you communicate something
that's hard to communicate, you get patted on the back. If you figure
out a simpler way to do something, people will buy you beer. If you
find a way to get more feedback---"Here's a big problem, and if I do
this day's-worth of stuff, I'll know how to solve it"---somebody will
say, "Hey, good job!" And if you face down a tough problem, and you
don't bow to your fears---you've got to acknowledge your fears, but
you don't bow to them---then even if you fail (it doesn't turn into
something that ships, but you show courage), then you get patted on
You probably don't mean just a pat on the back. What reward
system is built into XP?
It's really subtle. The primary one is tribal, psychic. Peer
recognition is the number one thing.
Just the satisfaction of knowing you got something to work---
And everybody else knows it too. Imagine 10 programmers, 2
QA people, a project manager, and a couple of customers in a big bull
pen. They have small, private cubbies around the periphery, and in
the center are computers---four, five, six of the fastest machines you
can get, each set up so that two people can work comfortably in front
of them. Now, if somebody does something cool in that environment,
it's not five seconds before everybody knows it. And then you do the
hip-hip-hooray, or everybody shakes your hand, or whatever.
To what extent do you think this approach scales?
My first strategy is to scale the problems down to the
approach. I don't get called into projects that have 100 people on
them. But I've talked to plenty of people who have been on projects
with 100 people on them and who've said, "The project was canceled,
but if we had 10 people, we would have just done it," or, "The project
was successful, and what happened was five people went off and did
it. One person made sure the other 95 didn't get in the way."
Is that the extent to which XP is compatible with the
company that insists on allocating headcount up-front for fear of
losing their budget?
There's so much fear in that kind of circumstance. I've
talked to and dealt with managers whose self-worth was tied up in how
big their project was in terms of headcount. Somebody like that is
bringing so much fear to the table, the chances they'll be successful
No matter what they do.
Right. Language matters nothing. Methodology matters
nothing. Nothing else matters. Somebody coming to a project with that
much fear is going to fail.
You have to be devoted to delivering the most valuable software you
can to your customers. Nothing is more important than that. Then you
have a chance to succeed.
Speaking of language, do you feel XP works best with
Smalltalk? How well does it apply to other languages?
It really comes down to the fundamental function of the
change-cost curve. If you have a language/environment/culture that
can keep that cost-curve down, then you can make XP work.
Maybe you ought to explain the cost-curve briefly.
It's the measurement that says the cost of change [in
software] rises exponentially over time. It says that if you catch a
problem in requirements, it's a dollar to fix; in analysis, it's $10;
in design, it's $100; in implementation, it's $1000; in test, $10,000;
and in production, it's $100,000 to fix. An earlier article I wrote
 tells the story of a radical requirements change two years into
production, including migrating all the live data and everything, and
how we did it in 2X or 3X the time it would have taken to program it
that way in the first place.
That's not exponential.
I don't think so! More like logarithmic to me, or maybe just
So there's at least one success story. Are there others?
Yes. That was, I'm happy to admit, a very special kind of
project---the very latest technology, very smart people, management
that really kept their hands off (for good or ill).
But the approach has worked in big companies also. The C3 project at
Chrysler is kind of an XP poster child. There's a project at Ford of
similar scale. They report dramatic success.
What is the scale?
10 programmers, working productively indefinitely. I can't
say it's 10 man-years or 50 man-years, because as long they can change
the system, they will, and that number will keep growing. But ten-ish
programmers seems to be some kind of a maximum for [vanilla] XP. It
scales down to two or three people very nicely.
Companies like Chrysler and Ford obviously have ongoing
commitments---at least I know Chrysler does. Can they corroborate the
benefits by comparison to non-XP efforts?
Oh sure. At Chrysler, you talk to the customers and you ask
how much it costs to maintain this system versus the cost of
maintaining their other payroll systems. They answer that quality is
dramatically higher, it's less hassle, and it's being done with far
Can you name some other companies? Two is not quite
I'm doing some work with a bank in Munich with quite small
projects, but it's an organization that was never able to ship quality
software. Never. In living memory of not shipping anything on time, we
put out two pieces of software---one with three developers and one
with two---that everyone's very happy with.
These people had worked on prior failed projects in that
Sure. Its environment bred failure.
What was it about the environment? Was it the fear you
Every case is different. In this one it happened to be that
there was no feedback. If you were successful, nobody said anything,
and if you failed, nobody said anything. Mediocrity just set in.
Was communication in general a problem?
Near zero communication. When I got there, they asked, "When
will you be done with analysis?" I said, "When you shut down the
project." In a six-month project they'd usually spend two months
writing analysis documents, and then they'd outsource the
implementation. Over and over again they'd do this, over and over
again they'd get crufty software, over and over again they'd ship
late, and the customer would be unhappy. There was no feedback, so
there was no reason to change.
And they had oodles of money to spend.
They're a bank!
Now, what exactly are the core practices of XP?
There's the PlanningGame
, which is the requirements
process. There's simple design; refactoring; the testing
strategy---which combines unit tests you write before you write the
code and functional tests that customers write. Then there's pair
programming, continuous integration, collective code ownership, coding
standards, and metaphor.
Let's start with the PlanningGame
. That's just vanilla,
Oh no no, of course not! The key insight, which I didn't
know was the key insight until PeteMcBreen
pointed it out, is that
you need a whole lot less work on requirements in order to estimate
and set priorities than you do in order to program.
So XP says, do a little bit of requirements work across the entire
system, enough so that you can estimate, and enough so that the
customer can look and say, "I'd like three of these and just one of
those, thank you."
The basic unit of requirements is called a story, which you can think
of as a use case that a customer doesn't mind writing.
Because it's shorter than normal?
It fits on an index card---a real, physical index card.
À la CRC, where you keep people from blathering through
sheer physical constraint.
Right. You say the three most important sentences you have
And so you say what the system can do, and you lay it out. Then the
programmers estimate, basically assigning a cost to these things, so
that you can go back to the customers and say, "Well, do you want this
for 10 or this one here for 3?" Given a choice without the costs, the
customers will always pick the Ferrari over the Volkswagen. But when
you explain the costs and their budget, they'll say, "Oh well, perhaps
we get the Volkswagen today and the Ferrari later."
That's the PlanningGame
. Then there's simple design...
Which states that the correct design at any moment (1) must
run all the test cases, 100%, and (2) is the simplest design that has
no duplicated code (and even subtler kinds of duplication, like
parallel class hierarchies). You have to say everything once and only
So it's a minimalist design that just gets you by, without
No no no. When somebody reads "just gets you by," they
think, "Oh, well, this is just hacking." Sometimes you have to work
very hard to get rid of extra stuff. It's critical, and it's a skill.
And that's part of refactoring.
Yes. Tufte  has this exercise where he says you can
design your graphs any way you want. Then you take out an eraser and
start going through them, erasing anything you want as long as you
don't lose any information. That's what you do to the design. You say,
"I thought I was going to need polymorphism here. But in fact there's
only one kind of object, and I can just fold it into this other
object. So I'll get rid of it." That's the right thing to do,
according to XP.
When do the test cases come into being?
There are two kinds of test cases. From the business
perspective, the heartbeat of XP is iteration, which is canonically
three weeks but might really be one or two or four weeks, but not more
than that. And in one of those iterations you commit to delivering
some stories from the PlanningGame
. Every iteration must provide
business value. You can't go away for an iteration and say, "We need
to refactor for three weeks. Go away and don't bother us." That's
against the rules.
By the end of the iteration, each of those stories is turned into a
set of functional tests. They're the customer's way of saying,
objectively, "If you pass these tests, we're willing to believe that
the software works." They come up with the set. Now, it might be hard
to make those tests run, or it might be trivial to make them run---it
doesn't matter. It's what the customer thinks is important. And
they'll get better at writing their tests as time goes on.
Is that all there is to an iteration?
No. Within an iteration, you do another level of
planning. You break the stories down into what I'll call "engineering
tasks," which people sign-up for and then estimate---very important to
do them in that order.
Suppose I've got this task: I'm going to export the DB40
transaction. The first thing I do as a programmer is ask for
help. "John, do you have a couple of hours this morning?" You say,
"Sure," because the rule is, if you're asked for help, you say yes.
So we sit down together. Maybe we do a little CRC cards, maybe we talk
to a customer to find out more about the DB40 transaction ... and then
we say, "What's the first test case?" We sketch out all the test cases
we can imagine for DB40 transactions, and we start implementing
them. First we write the test case, and then we say, "Hmm, this can be
easy or hard to implement." If it's going to be hard, then before we
do anything we ask, "Is there a way to refactor it so it'll be easy?"
If there is, we refactor it on the spot.
Are you talking about writing the test case, or the code
The code under test. Actually, writing the test case
oftentimes drives changes to the design. If it's easy to write tests
for the code, it's probably good code; if it's hard to write tests
for, it's probably bad code, or a bad design.
Anyway, you go into this little cycle where you implement a test case,
then refactor [the code under test] so that it's easy to satisfy the
test case, and then you satisfy the test case. If there are new
opportunities for refactoring, you refactor, and then you do the next
test case. You keep that going until you can't think of a test case
that will bomb.
Which brings us to PairProgramming
. You've already talked a
bit about it; maybe there isn't much more to say...
Ah, but it seems to be a sticking point with a lot of
people. They say it just couldn't be productive enough, which simply
isn't true in my experience.
What's the alternative---individuals in cubbyholes not
talking to each other?
Yeah. I think the dysfunctional alternative is people with
their heads down and blinders on not talking. Code reviews are a step
toward better communication.
To me, the advantage of PairProgramming
is that you have a
much finer grain of change and insight and accountability. You can go
a long time between code reviews; it's like having one make-or-break
exam per semester...
Instead of quizzes every Friday.
Right. You don't necessarily learn until it's too late.
What about continuous integration?
Some people talk about having nightly builds.
Yeah, well, nightly builds is for wimps. What's extreme is
doing four, five, six builds a day.
So we're working on our DB40 transaction. All the test cases we can
think of are running; we've done all the refactoring we can see to
do. And maybe it's taken us two or four or six hours. We look at each
other and say, "Okay, time to integrate."
It's best to have a dedicated machine for integration. So we go to it
and load the latest release, which may have some changes from what we
started from, but probably not many because it's only been a few
hours. We load our changes on top, and we resolve any conflicts---two
people changed the same method, so we have to figure out how to fix
Then we run the test cases, and generally they all run at 100%.
That's everybody's test cases. Everybody else is writing test cases
at the same speed we're writing them. If there's a problem, we fix
it. If we can't fix it, then we have to start over---go back and make
bigger changes. But typically everything runs at 100%. And we release
I can see that happening four or five times a day. But when
Microsoft talks about nightly builds, they're talking about 30 million
lines of OS code---
-that they recompile from scratch. With tools like they
have, that's probably the best they can do. I happen to be working
with tools that can handle this four-or-five-times-a-day thing in a
reasonable timeframe. A whole integration takes you 5-15 minutes.
But this is where the cynic is going to cry foul and say
we're talking about vastly different scales.
I didn't say you could build Windows NT this way. If this
doesn't scale up, some of the things people recommend for projects
like NT don't scale down. Doesn't bother me; it's not my client. My
clients have medium-difficult problems, they have medium-size teams,
they have poorly defined requirements that are changing all the time,
and they need to deal with the situation.
Fair enough. Want to move on to code ownership?
I was talking about it with Cope [JimCoplien
this is our favorite fighting topic. The rule is, if you see a problem
with code anywhere in the system, you fix it.
So we're sitting there with our DB40 transactions, and we say,
"Y'know, if this export object over here was just structured this way,
it would be really easy for us to do our stuff." If it would clean
things up elsewhere, we just do it.
No matter who wrote the code?
It makes absolutely no difference.
You're assuming some kind of locking scheme to prevent
It's more effective to use optimistic change control with
So anybody can change anything, anywhere...
Yup, absolutely. If you see it, and you got your partner
there, and you're going to run the tests within a few minutes---so
it's not like you're going to break something---you just do it. And
the system's going to get better.
Now, I came up with this because I was working in strict individual
code ownership shops, and we'd say, "Gee, we keep calling these same
three methods in this object. Why don't we just make a method in the
object that calls the three methods for us?" "We don't own that." "But
the guy's just across the hall-" "Naah, don't wanna bother him."
The pace of evolution in projects that use individual code ownership,
in my experience, is glacial compared to what is possible to do, in a
controlled way, if everybody takes responsibility for making all the
code as good as they can make it.
Has this been without pitfall?
Yes. It's just not a problem. You've got to have collective
ego instead of individual ego. That's the hardest problem, so that no
one comes up and says, "Hey man, you changed my class."
Today I made a change in the stuff I was working on, and somebody
said, "Ooh, when she gets back from vacation, she's really going to be
mad!" And it was like they were from a different planet, because I
just don't think that way.
When is she getting back from vacation?
Monday. And that's why I'm going to be in New York!
Everybody's got to agree on where the tabs and the spaces
go, even if it's not the way you would have done it. You can format
your code any way you want; you just can't do it on my team. There's
just no discussion, because there's so much friction. You look at a
method and you think, "Arrgh, better reformat this so I can deal with
It gets into this collective ego thing. If you deliberately give up
the right to format code and to choose variable names however you
want, you have a little less ego-involvement in the result. There are
people who just won't do it. That's fine; they just can't be on my
team, because it doesn't work.
I said the first thing you do with a task is you say, "Hey, who can
help me with this?" You're not joined at the hip; I might pair with
you in the morning and somebody else in the afternoon, and somebody
else again tomorrow. People float around a lot. So you have to sand
the rough edges off people who take such inordinate pride in these
Don't you ever notice pairs bonding and becoming cliquish?
If it does happen, then you ask one of them for help.
Who's "you"? Just anyone else on the team?
Ideally just anyone, although there is a designated role of
coach on an XP team. The coach is somebody who typically doesn't take
responsibility for engineering tasks, or does so at a vastly reduced
rate. His primary responsibility is just helping, having the view over
everything, watching the process, sniffing the air, watching people's
body language, listening to the buzz.
It's really funny for me now. I'll walk into a room [of developers],
and it's totally silent. It's the most unhealthy environment for
producing software. An XP team at work is like an Italian
family. There's this constant buzz, and people are throwing stuff back
and forth, and there are interruptions---but if somebody doesn't want
to be interrupted they say, "No, I'll talk to you later."
But there's this buzz, and you can ride it; you can become attuned to
when something's wrong in the buzz and get good at figuring out how to
fix it. It's a really cool feeling.
Fascinating. I want to get back to the roles in an XP team,
but let's talk about metaphor.
There's a justifiable fear that a process like this will
diverge, that the system as a whole won't hang together, that it won't
have a single story to tell. There are plenty of systems that don't
have a single story to tell---they're just agglomerations of
features. And it's a shame, whether it happens internally or
So the first thing I do with projects now is try to identify a
unifying metaphor or set of metaphors. In C3, the payroll system is
like a manufacturing line: there are bins and parts and stations, you
take parts out of bins and put them in other bins---that's how it's
In the life insurance system I worked on, there were several different
metaphors that overlaid each other in an interesting way.
Double-entry bookkeeping was one metaphor at the bottom. There was
this idea of contracts---in fact, all kinds of different business
objects going through various versions and navigating through
time. There was this very business-oriented metaphor of tasks and
tools that modify business objects. All these metaphors were playing
So the metaphor doesn't have to be a single thing, but there has to be
a unifying story. Then from within the metaphor you can generate class
names, method names, and variable names that have unity.
Who's responsible for coming up with the root metaphor?
So it's by consensus.
It has to be. And the team's understanding of the metaphor
is going to grow and mature over time. There's no question about that.
It doesn't have to be set in stone up-front.
No, no. The good thing about up-front design is that you
have this unifying vision. The bad thing is that big up-front designs
contain hundreds or thousands of guesses, most of which are probably
wrong. The metaphor takes the good thing about up-front design, this
unifying vision, and has us make each guess as we go along, and five
minutes later we'll know whether we were right or not. If we were
wrong, we fix it.
Isn't it possible that this metaphor idea will reintroduce
the exponential cost curve? If the metaphor is important, and if it's
something you need to have early, then doesn't changing it become more
expensive as you go along, perhaps exponentially so?
I don't think it's quite that expensive to change the
metaphor. There's a sense in which there's not a lot to it.
If you realize you need to change the metaphor because it just isn't
working for you, you'd have a big renaming task. You could do it
piecemeal---you don't have to rename everything at once, although you
might do it all at once just to get it over with. But you're going to
know very quickly whether that metaphor is right or wrong, and very
soon after that you won't be able to think without it.
Okay, let's get back to those roles. You mentioned one, the
Well, the heart of it is really the programmer. It's called
"Extreme Programming," and it's like programming, and programmers are
the most important thing about programming.
All right. You've got programmers, you got the coach. Who
You've got the customer, whose job it is to make business
decisions and to provide detailed explanations of the requirements
during implementation. So, ideally, the customer sits with the team.
But lots of people object to that for reasons that don't make economic
Oh, because these people are "too important." You're willing
to tank a five million dollar software project, but you're not willing
to spend $100,000 a year to have someone sitting there who actually
knows about payroll or trading or whatever it is. That doesn't make
There are a lot of objections to nearly everything in XP, some of
which really shocked me. But that's one I just don't accept.
Have you felt inordinate resistance to XP?
Yes, and in a very, very emotional way.
Why do you think people react to it strongly? They say if
people react strongly to something you're doing, you must be doing
That's what I keep telling myself. Now, not everybody is
trying to kill me. There are people who come up and kiss me on both
cheeks---which is why I'm growing a beard. There are people for whom
this really resonates. They say, "Why are you calling this 'extreme'?
This is just how I live my life. I can't imagine living any other way,
and I think it's great that you're describing it."
But there are some absolutely rational arguments where you could say,
"Well, what about x, y, and z?" And I'd have to say, "Yes, you're
right." How do you get 100 people all working together on the first
day? I don't know. But then there's a whole host of people who are
just extremely angry that we're saying the things we're saying.
Is there any correlation between that group and those who
have a vested interest in the status quo?
Oh, it's gotta be. Even if your vested interest in the
status quo is your fear.
Oftentimes people really pride themselves on things---like the ability
to handle a case tool or knowing the ins and outs of every bit of
UML---that XP just doesn't value. Somebody like that is going to be
ticked the first time (and the second time, and the twentieth time)
you come along and say, "That's lovely, but we don't do that."
Do patterns fit into XP, and if so, where?
Yeah, absolutely. Metaphor is one kind of global thinking
that goes on in XP, and patterns are the other. As a pattern writer,
I'm thinking on a very large scale, typically. I'm trying to
understand how my patterns fit together with each other and with other
patterns that I know. I'm thinking on a large scale; I'm playing a
big, big game.
Once a pattern writer has done that, though, the global thinking is
implicit in the patterns. Now, you can't just follow them by rote and
magically get good answers. But there's a sense in which the solutions
you come up with by following the patterns are guaranteed to have
certain global properties. COMPOSITE  is going to be composable,
guaranteed, if you do it right. STRATEGY guarantees a certain kind of
Now, are you talking only about design patterns or the whole
The coding patterns play into it also, as do Martin
[Fowler]'s analysis patterns , and domain-specific patterns.
How about organizational patterns?
I think XP in a way is a set of organizational patterns.
But to me, that's why patterns are important to XP---although we don't
use all 23 [GoF patterns ], frankly. We use five of those patterns,
six of the analysis patterns, and most people do coding patterns,
whether they're my coding patterns for Smalltalk  or their own set
of coding patterns for Java.
But simplicity is one of the values. You don't want to shove
everything you can think of into a system just to prove you can. You
do the things that have a lot of leverage, and you don't do the other
Is that what people mean by YouArentGonnaNeedIt
That's a reminder to stubborn folks like me to not abandon
the search for simplicity too soon.
Somebody will tell me, "Here's this design, and I gotta do this and
this and this, and tomorrow I'm going to need this, ta-da ta-da... So
I can't do it this simple way; I gotta do it this complicated way."
And I say, "You aren't going to need it."
"Yes I am. My next task card, my next test case, the next story in the
next iteration tells me I'm going to need it." I say, "You're not
gonna need it." And they say, "I know I'm gonna need it."
"How would you behave if you didn't need it?" I ask. "Well, I'd just
do this simple thing." "Okay, do that." (That's "You aren't gonna need
"Oh, all right." And they go and do the simple thing.
Later they say, "Oh, I see. I didn't need it." Or, "I did need it,
and it was in some shape that I had no way of understanding until I'd
done it the simple way."
Another thing YouArentGonnaNeedIt
does is it ensures a short
feedback cycle. If you have to do two week's worth of design before
you can code something, you've got a very long feedback cycle.
It seems this three-some-odd-week iteration cycle is crucial
on many levels.
Yup. XP has lots of interesting self-similarities. You're
implementing one test case at a time, one task at a time, one story at
a time, one iteration at a time, one release at a time---which is a
set of iterations lasting a few months.
When you say "you," do you mean an individual?
A team. I mean, the scale changes, from a pair to the team
as a whole.
So there are self-similarities along that axis as
Time to go meta. Where do you see XP going for you personally? What's
your agenda, if any?
Well I've actually given a fair amount of thought to this.
Jeff Eastman asked me about it in Germany six months ago. He said,
"Why do you do this? Why are you compelled to go and tell people about
XP instead of just enjoying programming, and maybe helping your team?"
You know, why do you publish books and talk at conferences and stuff.
I didn't have a good answer, and it bothered me a lot. But here's an
answer I can live with.
I hate feeling that I've done a good job---technically the best job I
could do---and my project failed anyway. It spoils the fun of
programming for me to think that no matter how good a job I do, no
matter how much aesthetic pleasure I take in my work day to day, the
whole thing could still tank. Oftentimes it's simple little things
that programmers have control over that could make the
difference. It's important to me to take what I've learned about doing
those little things and tell lots of people about it.
So there's a sense of mission, and an aesthetic component,
and a self-fulfillment component---
And a big human component too. There are dehumanizing things
about programming the way it's practiced at my clients, before I get
there. It's very important to me to stand up and say, "Stop. This is
bad for everyone. Do this other thing."
You mentioned books. Can you tell us about them?
Sure. A small group of us are working on them, currently
, and myself. We
got together at OOPSLA '98 and asked ourselves how we were going to
exploit the publishing industry to help us get the word out about this
We could have gone off and tried to write
, 800 pages, etc. But it wouldn't have
been extreme. The extreme way to write books is to write little
books. Figure out what the most important stuff is, and publish that
first. Then you take the other stuff.
The first book is something I wrote in a manic rush called Embrace
Change---because XP assumes change is the norm and so you should deal
with it. I hate listening to programmers whine about customers
changing their minds. Yes they do; now, what are you going to do about
it? Anyway, Embrace Change is a rather philosophical book, which is a
departure for me. I'm still a lover of the part of the patterns ethic
that says you've got to talk about stoff [substance]; we can't just
float in the clouds.
On the other hand, what came out in this first book is kind of a
manifesto, and I'm not going to apologize for it. It has a role to
play in getting people to think about this stuff. It tries to make a
convincing case for XP without spending the pages it would take to
tell people how to actually do it.
Any ETA on that, by the way?
Bound books by August?
Yeah, bound books. I have twenty some-odd marked-up
manuscripts, which I just have to have the guts to go through...
Not including mine---sorry!
Well, I'd love to have that one.
So the five of us worked for a while at OOPSLA, and then we had a
three-day workshop in North Carolina where we asked ourselves what the
next book would be. We needed a more practical, hands-on,
how-to-because people are going to be frustrated with Embrace
Change. You read that book and say, "Yes! Absolutely! This resonates
with me. I wanna do it." The next thing you say is, "I don't know
how." We know that's going to happen, but it's how we can get the
books out quickly. So we're going to take that risk.
But there's a lot of support out there. There's a lot of material on
the Web, and many people are willing (on Wiki*) to answer questions
and help people get over the hump.
Every month I'm contacted by another team that says they're going to
do stuff extreme. They heard me talking at OOPSLA or wherever, and
they just decided to do it. They've read the stuff and they did it,
and now they're having these problems, or now they love it, or
whatever. So it's already possible for people to do it.
Anyway, the second book is called Playing to Win, and we quickly
realized we had to cut down its scope---we couldn't talk about all the
practice of XP. So we thought up the worst situation we could be in
before adopting XP: The project is already late, morale is dropping,
management and the customers are getting nervous. Then we asked what
XP book we'd write for someone in that situation.
Well, the two things you've got to do to get things under control are
planning and testing. You've got to be able to measure where you are
today---that's the testing part. And you've got to be able to present
alternatives for tomorrow, so the business can start steering
projects---and that's the PlanningGame
stuff. So the second book is
going to cover those two topics in depth.
Then we'll listen to what the community says they need explained
next. Either other people will fill those roles---people in other XP
projects will gather some fabulous experience that will go into books,
I'm sure---or we as a team will tackle the topics as they come up.
It's really about applying XP exactly to publishing. Instead of
having the four-year process to write a 700-page book, we're going to
have the four-year process to write five 150-page books---and make
I have a feeling these will be popular books. The main
challenge I see, apart from figuring out how best to exposit all this,
would be giving them a single voice. I know that was a challenge with
GoF. The way we solved it was basically to have one person do the
And you know, that's just not extreme. The way you get a
consistent architecture in XP is by making sure the team is
communicating on a very fine-grained basis. The way we did it on the
second book was with Wiki. We spent three days together on Wiki, 12
hours a day.
I pride myself on my writing. I know you do too. I've worked hard at
it, and I'm a pretty good writer. The depressing thing about what we
came out with at the end of three days is, I couldn't tell what I had
written. Because everyone had been touching everything, it already
sounds like it was written by one person.
But does it sound good?
Yeah! It's a validation of the principles that you can apply
the process to something as different as writing and get interesting
results. And, practically speaking, it's nice not having to find that
Well, I certainly can't wait to see this, because if what
you say is true, then this alone is a huge step---being able to make
collaborative writing sound like one person's work...
Exactly. My favorite programming language these days is
English, and every day I'm humbled at how much I have to learn about
programming in this language, both individually and collaboratively.
Oh, no question about it. We are all good at Wiki, and it
was so neat doing it in a room together. All of the things Wiki gives
you---you make a half-baked statement, and when you come back later
somebody's filled in the other half, and you didn't have to do
it---it's just a cool feeling.
Only it was a hundred times more intense [than the public Wiki]
because of the quality of the people and the fact that we were in the
same room and were making changes on a minute-by-minute basis to a
small set of pages. This thing evolved very quickly. And it never
felt like we were writing fast. At the end of the first day, we threw
away everything we'd done, of course; software's like that. But after
the next two days, we had 120 manuscript pages.
You had some kind of coherent amplification going.
Right. When I was writing Embrace Change, I would get on a
train to Munich, where I had this project, and I would write for two
straight hours, heads-down, really productive----you know, things just
flowing out. I never had that feeling with this collaborative
process. I'd get two good paragraphs out and then I'd have to go read
something. I never got into that solo flow.
But I just realized something: all five of you write
well. None of you has to be made up for in that department. But I
still wouldn't expect five good writers to come up with something that
sounds like the work of one person. Any piece of it might sound good,
but the whole will sound disjoint. So I'm dying to see the results of
this Wiki exercise.
Any parting thoughts?
There will be a significant number of people for whom XP
will make perfect sense, and they can go out tomorrow with no fear or
barriers and just start implementing this way. And there will be a
significant number of people for whom this sounds like suicide. I ask
those people to give one thing about XP a try---I recommend the
testing stuff or the PlanningGame
---before saying, "No, this isn't
going to work."
* Short for "Wiki Wiki Web," WardCunningham's communal web pages
 Zinsser, W. On Writing Well
, New York,
1998. Sixth edition.
 Beck, K. "Extreme Programming," C++ Report
, May 1999, pp. 26-29, 44.
 Tufte, E. The Visual Display of Quantitative Information
Graphic Press, Cheshire, CT, 1983.
 Gamma, E., et al. Design Patterns
, Addison-Wesley, Reading, MA,
 Fowler, M. Analysis Patterns: Reusable Object Models
. Addison-Wesley, Reading, MA, 1997.
 Beck, K. Smalltalk Best Practice Patterns
. Prentice Hall, Upper
Saddle River, NJ, 1997.