Bill Venners: On a recent plane flight I was watching a movie called Possession, in which Gwyneth Paltrow and Aaron Eckhart play two literary scholars. They discover some letters written between a Victorian poet and his up-to-then secret love interest, and read them aloud. These letters were beautifully written, and it made me think about the way technology affects our minds. Letters from the 18th and 19th centuries don't sound like emails. They don't even sound like modern letters. They sound richer and more contemplative then modern correspondence.
In the days before writing, people had to use their memory more. Perhaps their memory was better than ours, because it got more practice. In the 19th century, before the fountain pen, people wrote letters with quills they dipped in ink. If they screwed up at the bottom of the page, they had to write the whole page over again. So they likely thought more before each act of writing than people do now in this age of the backspace key. Back then people planned out more of the text in their head, and kept more of it in their head, before committing it to paper. And I imagine all that practice helped them get good at that kind of thinking.
Extreme Programming's emphasis on refactoring over up-front planning would make little sense outside the context of our current technology. We have a backspace key and the ability to select text. We can copy text, delete it, duplicate it, or move it in a few keystrokes. We also have scripting languages and refactoring IDEs that help us make changes to existing code. These technologies are empowering, but is there a cost? Because we don't need to think ahead as much, we won't practice thinking ahead as much. Will our abilities to think ahead decline?
Ward Cunningham: It may be that we're thinking differently. To say whether that difference is better or worse would be a value judgment that would require looking at a much bigger picture. I was told once that to learn to write a letter, you start writing the letter. If you make a mistake, you set the page aside and you start writing the letter over again. You'll get farther, but you'll make another mistake and you'll start it over again. Eventually you'll get the letter written. If you do this for a week, you change the way you think about the production of words to the point where you tend to write whole sentences, whole paragraphs that just flow from the pen. Nobody says, "Make a master plan for the page. Figure out what paragraphs are going to do." It's more a process of opening machinery in your mind that already does it. The way to practice that is to write letters, and if you make a mistake, write it over again and over again. It is an incremental approach to mastering the use of some capability that is intrinsically human. As I spin word after word out here in conversation, I'm using that same machinery.
In XP, we're saying that for a group of people to work together as a high performance team, they must take information that an individual might be able to manage in the back of his or her mind, and put it on the screen. Once the information is out of an individual mind and on a screen, it is subject to our collective use. And with pair programming, that is reasonably efficient. If you are sitting there, there are enough clues. Pair programming takes an act of creation that could go on in the back of your head if you were programming by yourself, and puts it on the screen where it can be watched. Because it can be watched, it can be shared. Because it can be shared, you get a magnification. Technique flows through the organization that wouldn't flow otherwise—technique about how to think.
By insisting that the bulk of activity happen on the screen, we take an individual activity and make it a collective activity. If I can't tell what you're thinking while I'm watching you type, we're not pair programming right. Often, the only conversation that happens during pair programming is conversation about what was not visible on the screen: "Why did you do that? What made you think that was the right thing to do?" The only thing we need to talk about is what's not manifest there on the screen. The longer we can go without talking the better.
One of the things I love about pair programming is sometimes you just point to the screen, and the other guy says, "Oh," and does something differently. Just directing the focus around on that screen is often enough. I think that has a lot to do with the efficiency of a program text to explain and represent a complicated thought. In other words, a complicated thought has a representation on the screen as this syntactic element called a computer program. I love computer graphics, but every system I've seen to try to turn programming into pictures has lost that syntactic element. There's something about syntax that makes it very precise for reading. I love photography. A photograph will tell a story. But words tell a story even better. Words are more versatile. You can paint a verbal picture that's much richer than you can photograph.
So if you program in the XP style day in and day out—if you practice to the point where what you do is on the screen instead of in your mind—how would that change other things you do in your life? You are using faculties differently. It is changing the way you think.
Bill Venners: It sounds a bit like living in the present instead of worrying about the future.
Ward Cunningham: Yeah, there's a zen feeling to it. I actually think the XP style makes you better at predicting the future because you just get a lot more experience in seeing how things work. Most of our ability to predict is just based on some sort of internal modeling. If we write 10 programs a day instead of one program every 10 days, we just get that much more experience.
Bill Venners: If you don't spend that other time designing?
Ward Cunningham: Designing, or getting permission to design because somebody else wants to do the design, or whatever. Instead of whatever else we would otherwise do, we instead just do an awful lot of programming. So there's a lot of seeing what happens when you do something, and that makes you a great predictor. So despite the anti-design approach, it turns out we end up being great designers.
What you end up doing is this: in your head you think, "Oh! Oh! I know how this is going to come out!" But then you think, "Well, it will come out soon enough." You could discuss it, but it will come out soon enough. You see stuff coming, but you ask yourself, "How would I make things better by discussing it?" We're working together and you're programming away. I could say, "Wait! Wait! I know what's going to happen down here!" Well you knew what was going to happen down here. How does it help us get our job done for me to tell you what's going to happen down here? You could say, "Stop! I want to draw on the white board what we're going to do tomorrow, because I can see it coming." Well maybe I can see it coming too, but why make a commitment? It will come soon enough. So, we're certainly here and now, but I think we can become excellent predictors. It's just that we're careful not to depend upon prediction anymore than we have to.