of humor. And when Kent Beck says that it's a new, fun way of programming, I really believe that. I think that it really brings the fun back into doing some of the programming and some of the development.
Who gets involved in XP? Well, you can't escape. You really have a unified group of programmers working with the managers, working with the customers. And that's an essential part of XP, and getting involved in it.
When we take a look at what are some of the things that happen in an XP environment, well, there's pair programming. What is pair programming? Well that's something where you can no longer sit down and program on your own. You always do it in pairs. Now think about that. You've always got somebody looking over your shoulder, so if you type something in wrong, or you take a look at something wrong, or you get stuck, you have a second pair of eyes that's sitting right beside you. One of the things Kent Beck said on our December 5 show--he said you really work together. When you work as a pair programming, you work together, and he says that what happens is that you're looking over somebody's shoulder, kind of like backseat driving. So as you're looking over this person's shoulder, and you're saying, "Okay, I don't think it should be done that way. No, I wouldn't do it that way. I think I should program it another way." Finally, he said, you've got this keyboard on a long, long cord sitting in your lap, and you finally get sick of this person after about fifteen minutes of saying, "I'd do it this way. I'd do it this way." You hand the keyboard over to them, and it's their turn to front seat drive. And you become the backseat driver. It works very, very well. And you don't Extreme Program, you don't pair program, with the same person throughout the entire project.
Now, one of the other things that Extreme Programming focuses on is "test first" before you actually write any bit of code. This is one of the major problems that we have in traditional development. People can't really say what their requirements are, and for a long time, I really thought that that is similar to...in building construction, that we pour a foundation before we have a floor plan. The requirements of a system development project, in my mind, are very much the same as a floor plan. If you didn't have a floor plan, I can guarantee you that in my county in hurricane-prone Florida, that we could not get a building permit. If I said, "It kinda sorta is going to be this big, I'm not sure what this area is going to be, I don't know whether it's going to be covered with a roof," I can guarantee I wouldn't get a building permit. And no construction could start.
But in systems that doesn't happen. We say, "Well, I kinda sorta think it's going to be like this." And we have these to-be-determined areas. Well, number one, how can you know if your requirement is right if you don't know what it's supposed to deliver? If you don't know how to test it? And that's one of the premises of Extreme Programming, is that you come up with your tests before you actually write a line of code. And if you can't test it, it's really not a requirement. So that's a bit of a problem. Now, it may sound like we spend most of our time