Interview with Kent Beck and Martin Fowler

In its own way, extreme programming (XP) is as filled with excitement—and
hazards—as many extreme sports. In this interview, XP experts Kent Beck and
Martin Fowler, address questions about the world of extreme programming.

From the author of

From the author of

Martin: My understanding is that Ward Cunningham inserted small wires
up Kent's nose to reprogram his brain that way in the late 1980s.

Question: Does XP appeal to all types of software development or is it best
suited for small teams?

Kent: The first time I was asked to lead a team, I asked them to
do a little bit of the things I thought were sensible, like testing and reviews.
The second time there was a lot more on the line. I thought, "Damn the
torpedoes, at least this will make a good article," [and] asked the team
to crank up all the knobs to 10 on the things I thought were essential and leave
out everything else.

Martin: I certainly think that XP, as written, is best for small
teams, and indeed [I] don't encourage teams of over a dozen to use it. However,
I've been active with a project twice that size that has been using XP very
effectively, and certainly many of the principles of XP, including many planning
ideas, are usable by larger teams.

Kent: I won't claim that XP will work for hundreds of programmers
until I see it. It isn't really a question I care about. I'm more interested
in scaling in time and across different specialties. My experiences so far suggest
that it scales very well across time and perspective.

Question: How is planning an XP project different from planning a traditional
software project?

Martin: Answering this will require me to make three points:

First is the simplicity of the plan—we don't think a plan should
require you to be a guru with some complex project-management software.

Second [is] the fact that the detailed planning is done by the people
who are going to do the work.

Third, plans are not predictions of the future—just your current
estimate of how things will turn out. Such plans are useful, but they need
to be changed when circumstances change. Otherwise, you end up in situations
where plans and reality are in disagreement, and then the plan is less than
helpful.

Kent: We leave the plans on obviously worthless bits of paper to
remind everyone that the plans are not the point; the act of planning is what
creates the value. Contrast that with a recent Microsoft Project ad where a
guy sits alone in a darkened room in front of a bank of huge monitors displaying
fancy charts. Their tag line is "Excellent." I would change it to
"Doomed." Planning isn't about reducing projects to convenient abstractions—it's
about smelling and facing fear.

Question: Why is XP so popular around the world? What's up with that?

Kent: Because it's equally difficult for everyone. Each national
and business culture finds challenges and comfort in XP, but in completely different
areas. In Germany, I had a terrible time converting hierarchical communication
structures into social networks. A professor teaching XP in Mexico reports that
his students love pair programming, but have trouble writing enough tests.

Martin: For so long the choice has been between chaotic "code
and fix" development [and] complicated methodologies that seem to take
up more time than doing the work. XP strikes a useful balance that people have
needed for a long time. It also recognizes that software developers are professionals,
and therefore need to be given the responsibility to choose and tune their own
process.

Question: Why did you two decide to write a book on planning XP?

Martin: Last November I visited Kent's sumptuous estate, and as we
were walking around the grounds we talked about what needed to come next. We
felt that more material was needed on how to execute XP and that planning was
an obvious topic to talk about. We also fancied writing together; we'd done
a bit of that with the Refactoring book and it worked well. [Refactoring:
Improving the Design of Existing Code, Addison-Wesley,
1999, ISBN 0-201-48567-2)]

Kent: As I recall, I had just explained about the air gaps around
the replacement door on my aging trailer when we realized we wanted to work
together. (Martin, we don't have "grounds," we just have ground.
Now that the rains have started, I can't even really say that with any conviction.)

Martin: It was strange to do. I'd always written books solo before.
However, it worked unbelievably well. We tossed chapters back and forth and
our writing style is so similar that I couldn't tell who'd written what—which
made us both fearless in reworking existing text.

Kent: I call Martin my Chapter Fairy (fortunately, he's confident
enough of his masculinity that he can take this). I would get up in the morning,
go to my mailbox, and find another chapter or two. Not wishing to be shown up
by a mere Brit, I would bang out a couple of my own.

Question: How does XP compare to traditional software methods like the SEI's
PSP or Rational's RUP?

Kent: I think the SEI is firmly in the modernist camp, trying to
reduce software engineering to something numerical, predictable, and machine-like.
XP is distinctly post-modern. It's philosophical roots are in complex systems
theory. In XP, we are looking to create the "ilities" as emergent
properties of the whole team acting according a set of simple rules, not through
centralized control. In business terms, this results in a team that's robust,
because no one person is a bottleneck, and yet can go fast when the way forward
is clear.

Martin: RUP is designed to accommodate almost anything. I've seen
old-fashioned high-ceremony waterfall fit into RUP, and XP fit into RUP. Indeed,
my objection to RUP is that it's too vague. You can easily cast XP as an instance
of RUP if you need to. Bob Martin's put together an instance of RUP which is
pretty much XP; he calls it dX (turn your monitor upside down to see the joke.)

Question: How does planning fit in with other XP tenets?

Martin: It's a key part of the picture. Planning is an essential
activity to making any complicated task work.

Kent: The technical aspects of XP are really preparation for handing
control over the scope and priorities of the project to someone with a business
perspective. You work hard at testing, refactoring, communication, and integration
so business can come in Monday morning and change the whole focus of the project
without the team crashing.

Question: What background and expertise did you bring to writing the book?

Martin: Lots of unsuccessful projects and a few successful ones.
We worked together on the C3 project, which was the first acknowledged XP project.
The core planning ideas here are the ones that Kent put together for that. Since
then, we've done XP on other projects and folded what we've learned into the
book.

Kent: We also brought our history as writers. Martin and I have talked
a lot about writing. We always strive to write in a casual, approachable voice,
and maintain precision. We also wanted to write a short book. Our goal was to
get under 100 pages, which we missed badly, but we did manage to delete 30%
of the text of the book in the last week of real editing.

Martin: Also, there have been a lot of contributions from the rest
of the XP community. XP is a large movement these days, and folks like Ron Jeffries,
Chet Hendrickson, Bill Wake, Ken Auer, Ann Anderson, Frank Westphal, Don Wells…lots
of people who add their experiences to XP.

Question: What one thing do you want software developers and organizations
to take away after they read your book?

Martin: Do a little planning every day. Expect your plans to change,
but remember that it's the activity of planning that counts—so keep your
plans simple and up to date.

Kent: Someone said XP was "making the world safe for programmers,
and programmers safe for the world." I love that! So, to the programmers:
Make honest estimates, track your actuals, and ask for help when you hit a business
problem. To customers: When you add up the estimates and you get an answer you
don't like, don't change the estimates—get creative about what you ask the
team to work on first. And, to project managers: Make problems visible and trust
your team to solve them.

Question: What are your plans for future projects and books?

Martin: I'm working on more Analysis Patterns material [Analysis
Patterns: Reusable Object Models, Addison-Wesley,
1997, ISBN 0-201-89542-0]. Hopefully, I'll have enough to get another book on
that topic out soon. I'm also putting various essays on software development
up on martinfowler.com. Many of these are linked to XP, but we'll see what topics
come up. One much-called-for topic is explaining XP to customers of software,
and I suspect you'll see us do more collaboration on that.

Kent: Two topics interest me at the moment. The first is test-first
programming, which turns out to be more of an analysis and design technique
than a testing technique. The second is the application of XP-like techniques
to general business topics. At the moment, I'm writing a series of essays. I
don't want to think about another book.

Question: What are your predictions for XP in the next few years?

Martin: I think you'll see XP grow with more people and projects
using it, and more knowledge appearing of how to do it well. There'll be new
people coming out of the XP community who will write really good stuff. You'll
also see other processes being markedly affected by XP. Already it's amazing
how much other processes have adopted of XP's practices while opposing XP. I
think perhaps the most important thing about XP is the cattle prod it's been
to other methodologies.

Kent: It will grow rapidly. The barnacles of hype and hucksterism
will attach themselves. Some projects will succeed, others fail. It will expand
beyond programming. And I'll get that stupid door fixed.