e-Talk Radio: Beck, Kent, 5 December 2000

you say to me, "You know what? Chicago is great this time of year." Is that similar to the types of changes that happen in XP perfect projects? The types of things where you really say the requirements are just changing all over the place. Nobody has any idea what they want until they see what they don't want. Are those the things that are really perfect for extreme programming?

Kent: Well, certainly as the frequency and violence of changes increases, it's more and more valuable to be able to deal with that, those changes, gracefully. If you had absolutely fixed requirements, and you had perfect engineering knowledge, there's probably some more optimal way than XP to schedule the engineering of that task. But as the frequency of the change goes up, and the frequency of the change in the technology goes up, in other words, the more you learn, the more you want to be able to plan, to make all sorts of decisions, not just to…planning decisions, estimation decisions, analysis, design, implementation, tools, technology decisions, as you go instead of making them all at first. The kind of projects that I'm involved in, people are really ignorant at the beginning. And yet there's this notion that you ought to be making, you know, if only you were a good programmer, you could make all your decisions there when you were stupid. It doesn't make sense to me. It makes much more sense to be able to say, "Oh, I see. The design of the system should be like this." And then things would be simpler, and then you change it. Whether that's a month into the project, or ten years into the project. You should be able to take what you learn and put it into the system. That makes the system that much more capable for the next thing you need to do.

Carol: Right. One of the things that people have said to me is that their first impression of XP is that it's almost, in some cases, anarchic. It's the reason…It's justification for the programmers to say, "You know what? We didn't want any of that process stuff. The CMM stuff. That's just too much overhead. Let's just abandon all that and go back to just coding and fixing directly." And I don't think that's the case. But I wanted you to be able to respond to that.

Kent: Well, it certainly…One of the things I've discovered about XP is that it really… People see their fears in it, oftentimes. So the programmer's used to a lot of freedom, looks at it and sees, "Oh yeah, I have to write tests, and I have to program with other people, and I have to deliver early and often, and so I can't do all this pie in the sky design that I enjoy so very very much. So they see it as being lots and lots of structure. And the people who are used to very…processes from a more mechanical mindset, see it as total chaos. It's just programmers running around and doing stuff.

Carol: Right.

Kent: And the thing that makes it…There's a couple of rules, very simple rules, that make it not just anarchy. One of which is that you have to write tests before you write functional code. And the second is that you have to continually refactor the design.

Carol: And we will continue on that line in a few moments, after a few words from our sponsors, with more of Kent Beck.

And we're back with Kent Beck, who is one