Interview with Kent Beck and Martin Fowler

Like this article? We recommend 

Question: How did extreme planning (XP) originate?

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.

About the Authors

Kent Beck and Martin Fowler are the authors of Planning Extreme Programming (Addison-Wesley, 2001, ISBN 0-201-71091-9).