Vlissides On Beck

In the June 1999 issue of CppReport, JohnVlissides PatternHatching column 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. Now that I know that I would love to know more! -- RichardDrake

See SystemMetaphor and OOPSLA 97 paper (ExtremeArticle).

C++ Report, June 1999

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 [1], 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 unsuspecting victim?

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 conversation.

JV: Let's start off with a cook's tour of what XP is and isn't.

KB: 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 miserably.

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.

JV: There's that old adage about how you can't reuse what you haven't used.

KB: 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.

JV: Enter XP.

KB: 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.

JV: Except...?

KB: 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.

JV: 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 mindset?

KB: 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 process---this PlanningGame 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 say, "Fine."

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?"

JV: Incremental releasing, incremental testing ... there's a lot of incrementality here.

KB: 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 the back.

JV: You probably don't mean just a pat on the back. What reward system is built into XP?

KB: It's really subtle. The primary one is tribal, psychic. Peer recognition is the number one thing.

JV: Just the satisfaction of knowing you got something to work---

KB: 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.

JV: To what extent do you think this approach scales?

KB: 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."

JV: 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?

KB: 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 are miniscule.

JV: No matter what they do.

KB: 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.

JV: Speaking of language, do you feel XP works best with Smalltalk? How well does it apply to other languages?

KB: 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.

JV: Maybe you ought to explain the cost-curve briefly.

KB: 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 [2] 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.

JV: That's not exponential.

KB: I don't think so! More like logarithmic to me, or maybe just plain flat.

JV: So there's at least one success story. Are there others?

KB: 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.

JV: What is the scale?

KB: 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.

JV: 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?

KB: 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 fewer programmers.

JV: Can you name some other companies? Two is not quite critical mass.

KB: 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.

JV: These people had worked on prior failed projects in that company?

KB: Sure. Its environment bred failure.

JV: What was it about the environment? Was it the fear you mentioned earlier?

KB: 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.

JV: Was communication in general a problem?

KB: 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.

JV: And they had oodles of money to spend.

KB: They're a bank!

JV: Now, what exactly are the core practices of XP?

KB: 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.

JV: Let's start with the PlanningGame. That's just vanilla, everyday analysis?

KB: 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.

JV: Because it's shorter than normal?

KB: It fits on an index card---a real, physical index card.

JV: À la CRC, where you keep people from blathering through sheer physical constraint.

KB: Right. You say the three most important sentences you have to say.

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."

JV: That's the PlanningGame. Then there's simple design...

KB: 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 once.

JV: So it's a minimalist design that just gets you by, without any---

KB: 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.

JV: And that's part of refactoring.

KB: Yes. Tufte [3] 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.

JV: When do the test cases come into being?

KB: 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.

JV: Is that all there is to an iteration?

KB: 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.

JV: Are you talking about writing the test case, or the code under test?

KB: 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.

JV: Which brings us to PairProgramming. You've already talked a bit about it; maybe there isn't much more to say...

KB: 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.

JV: What's the alternative---individuals in cubbyholes not talking to each other?

KB: 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.

JV: 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...

KB: Instead of quizzes every Friday.

JV: Right. You don't necessarily learn until it's too late.

What about continuous integration?

KB: Some people talk about having nightly builds.

JV: Like Microsoft.

KB: 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 it.

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 our code.

JV: 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---

KB: -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.

JV: But this is where the cynic is going to cry foul and say we're talking about vastly different scales.

KB: 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.

JV: Fair enough. Want to move on to code ownership?

KB: I was talking about it with Cope [JimCoplien] yesterday; 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.

JV: No matter who wrote the code?

KB: It makes absolutely no difference.

JV: You're assuming some kind of locking scheme to prevent chaos.

KB: It's more effective to use optimistic change control with collision detection.

JV: So anybody can change anything, anywhere...

KB: 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.

JV: Has this been without pitfall?

KB: 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.

JV: When is she getting back from vacation?

KB: Monday. And that's why I'm going to be in New York!

JV: Coding standards.

KB: 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...."

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 things.

JV: Don't you ever notice pairs bonding and becoming cliquish?

KB: If it does happen, then you ask one of them for help.

JV: Who's "you"? Just anyone else on the team?

KB: 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.

JV: Fascinating. I want to get back to the roles in an XP team, but let's talk about metaphor.

KB: 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 externally.

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 set up.

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 together.

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.

JV: Who's responsible for coming up with the root metaphor?

KB: The team.

JV: So it's by consensus.

KB: 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.

JV: It doesn't have to be set in stone up-front.

KB: 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.

JV: 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?

KB: 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.

JV: Okay, let's get back to those roles. You mentioned one, the coach.

KB: 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.

JV: All right. You've got programmers, you got the coach. Who else?

KB: 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 sense.

JV: Such as?

KB: 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 sense.

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.

JV: Have you felt inordinate resistance to XP?

KB: Yes, and in a very, very emotional way.

JV: Why do you think people react to it strongly? They say if people react strongly to something you're doing, you must be doing something right.

KB: 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.

JV: Is there any correlation between that group and those who have a vested interest in the status quo?

KB: 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."

JV: Do patterns fit into XP, and if so, where?

KB: 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 [4] is going to be composable, guaranteed, if you do it right. STRATEGY guarantees a certain kind of flexibility.

JV: Now, are you talking only about design patterns or the whole gamut?

KB: The coding patterns play into it also, as do Martin [Fowler]'s analysis patterns [5], and domain-specific patterns.

JV: How about organizational patterns?

KB: 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 [4]], 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 [6] 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 things.

JV: Is that what people mean by YouArentGonnaNeedIt?

KB: 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 it.")

"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.

JV: It seems this three-some-odd-week iteration cycle is crucial on many levels.

KB: 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.

JV: When you say "you," do you mean an individual?

KB: A team. I mean, the scale changes, from a pair to the team as a whole.

JV: So there are self-similarities along that axis as well. Nice.

Time to go meta. Where do you see XP going for you personally? What's your agenda, if any?

KB: 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.

JV: So there's a sense of mission, and an aesthetic component, and a self-fulfillment component---

KB: 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."

JV: You mentioned books. Can you tell us about them?

KB: Sure. A small group of us are working on them, currently WardCunningham, KenAuer, RonJeffries, MartinFowler, 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 stuff.

We could have gone off and tried to write TheBigBookOfExtremeProgramming?, 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.

JV: Any ETA on that, by the way?

KB: August.

JV: Bound books by August?

KB: Yeah, bound books. I have twenty some-odd marked-up manuscripts, which I just have to have the guts to go through...

JV: Not including mine---sorry!

KB: 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 adjustments in-between.

JV: 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 voice.

KB: 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.

JV: But does it sound good?

KB: 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 single voice.

JV: 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...

KB: Without fascism.

JV: 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.

KB: 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.

JV: You had some kind of coherent amplification going.

KB: 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.

JV: 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?

KB: 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

(http://c2.com/cgi/wiki).

References

[1] Zinsser, W. On Writing Well, HarperPerennial?, New York, 1998. Sixth edition.

[2] Beck, K. "Extreme Programming," C++ Report, May 1999, pp. 26-29, 44.

[3] Tufte, E. The Visual Display of Quantitative Information. Graphic Press, Cheshire, CT, 1983.

[4] Gamma, E., et al. Design Patterns, Addison-Wesley, Reading, MA, 1995.

[5] Fowler, M. Analysis Patterns: Reusable Object Models. Addison-Wesley, Reading, MA, 1997.

[6] Beck, K. Smalltalk Best Practice Patterns. Prentice Hall, Upper Saddle River, NJ, 1997.

CategoryInterview