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

can be part of the process, as opposed to on the other side of the wall.

Kent: Well, sure. And you know, you've got two weeks, is a typical iteration length is one, two, or three weeks. And you don't do just one story in that amount of time, you do four or five, you size the stories appropriately, so that the team can accomplish that much. While you're in the middle of doing that, you say, "Well, you know, there was this great trick I learned in school. I can imagine needing it someday for this. But in the context of this story, right here, for these two weeks, I'll just do this simple thing." Well, a week later or a month later, when the time comes to do something more sophisticated, you look at the code and you don't have ego involvement. That wasn't the last word. You weren't trying to program for the ages a month ago. You were trying to get that iteration's stories done. And now the time has come to do something that's a little bit more sophisticated. And it feels good. You get to pull the tricks out of your bag once in awhile. But most of the time, you're getting away with doing really quite simple systems.

Carol: Interesting. Now, one of the things that comes up that I think has received a lot of pushback is this idea…It's either embraced, or it's pushed back…Is this idea of programming in pairs, that you…If you're on an XP project, you as a programmer have to have somebody else working alongside of you.

Kent: So here's the rule the way I state it. That is, all production code is written with two people at one computer. Now, you know, I'm not such a young guy anymore. I can program maybe four, five hours of really concentrated work a day. And so for that amount of time, I'm paired up with somebody. What you find is that you make far fewer mistakes, and you always have somebody there when you're a little bit afraid to tell you hey, it's okay, we can get through this.

Carol: We'll talk a little bit more about programming in pairs, and more about extreme programming after these messages. And we'll be back.

Kent: …..be tactical and completely focused on being tactical. You don't have to worry about, "Am I missing something big?" And the person sitting next to you is looking at the big picture and saying, "You know, you're about to do this thing. But there's this whole other approach that could just make all of this go away entirely." So, you know, when your partner spots that you're kind of going down a rat hole, they'll start feeding you helpful suggestions, which get so annoying after awhile. So you shove the keyboard over, and you say, "Okay, smart guy. Name that tune. Show me what you're talking about." Now, the roles switch. They become tactically oriented. "How am I going to accomplish this thing?" And you are starting to think strategically, but at the same time, you have a lot of motivation, because this person just stepped on your good idea, so you want to have an even better idea than they do. And the keyboard's flying back and forth every couple, three minutes. It's not like watching someone program. It's more like having a very dynamic conversation about your program, and you get the experience of programming at the same time.

Carol: Are people forced…When you program in pairs, it's not like in school, when you