from the outset that, oh gee, you either have to embrace XP entirely in order to do it properly, or don't do it at all. And I don't think that's the case. I think that you can pick and choose the pieces in XP that will work for you, and you can have a very successful project. One of my examples...I did some research with Software Quality Engineering before I developed my Extreme Programming presentation for ASM, and there they actually did a modified XP project. They didn't embrace everything in XP. It was just too much to embrace, and at the onset they picked and chose pieces of XP that would work for them and achieved outstanding success with some of their new Web site applications.
So I think that you can pick and choose the pieces that will work for you. Forcing people and saying, "You must pair program with that person that you don't like, just because XP says you must," I think is foolish. I think that you have to take it with a grain of salt and say, "Let's take the pieces that will work and let's reject those pieces that may not work in our environment." Does that seem to make sense, Danny?
Caller: Yeah. It's a good idea any time you're implementing any kind of a new process, like software inspection is one example I've seen, where there are the zealots like Tom Guild who say you've got to do it all this way or it's not going to work very well. But the approach that I take is more incremental. Let's take one step. Let's take one really good part of it that makes sense to implement and try that. And you just take the incremental approach and don't throw the whole thing out because you don't like one part of it. And I'd be interested to hear if anybody else has rejected the whole thing because of one really controversial part of it.
Carol: And I'll give the toll-free number out again, so that we could...You're welcome to stay on the line for a little bit, Danny, we may have other callers who might want to interact. It's 866-277-5369. And I think you're very right, that when the Yourdon method, when the structured analysis method came out, everyone said, "You must apply it exactly this way." And it was almost to the extent of having police, you know, structured analysis police. And I think that the notion of Extreme Programming police is something that just doesn't exist. And one of the neat things about talking to Kent Beck live is that you find out that he's a real person. You find out that he's a person that has taken a look at Extreme Programming, he's taken a look at object-oriented programming, and picked out the pieces that really seem to make sense. Not spending too much time iterating and iterating and getting the words exactly right in requirements. Actually starting to do them. So I think that makes a lot of sense. Danny, have you tried Extreme Programming at all?
Caller: No, I really haven't had the opportunity to follow it yet. I'm still waiting for the right moment to really jump in and try it. But some of my colleagues, there was one for example that said, "You've got to try pair programming. You've just got to do it." Once he tried it, he insists on doing it that way. Anywhere he does any programming. So there's certainly some elements that I'm willing to try. My background is more in