Pair Programming

Pair Programming is easily the most extreme feature of Extreme Programming (see Kent Beck's "Extreme Programming Explained" or http://www.extremeprogramming.org/ ).

What are the basic mechanics? Usually, one programmer is typing and thinking out loud about what needs to be done. The other sits and offers suggestions. Sometimes, the keyboard changes hands.

The first few times are not typical. You will spend time discovering tricks with editors and discussing personal work habits. You will find it exhausting, and neither will be unable to type for more than half a day each. Remember to pass the keyboard back and forth, and keep your paired days short.

After the novelty has worn off, you find that every partner is different. Nevertheless, the benefits seem not to depend very much on whom you work with.

What is one guaranteed benefit? All code written by two people is at least understandable to two people. Two people can maintain it, so others are more likely the find the code maintainable as well. Upgrades and bug fixing will always consume more of your time than the negligible first draft of a program. If your code can't be maintained, then you really cannot afford to ship it, no matter how useful the functionality.

Better, the two of you are thinking about the code in different ways. While the typer is thinking about one screenful of code, the companion is thinking about the effects on other code. Maybe this bit of functionality belongs elsewhere. Maybe this information can be encapsulated. Maybe we're making a bad assumption here. You catch many opportunities to simplify your code and improve flexibility.

It's hard to think about the big picture and the details at exactly the same moment. While you're thinking about one, you mess up the other. With twice the brain capacity, one of you can focus on the details, while the other checks the context and adjusts priorities.

I also find that we get more than twice the work done of either of us working alone. A speed-up isn't guaranteed, or even necessary, but there are good reasons why it happens.

Much of the time you spend in front of a terminal is wasted by context switching. "OK. Where was I?" You decide something must be fixed or refactored before you can make any progress. You spend twenty minutes making the extra change and you lose the thread. Your original idea goes cold. Or you postpone and never get back to the necessary refactoring. Worse, you may spend an hour restructuring code, then realize it was not necessary after all. There was a simpler way to solve the same problem, or you misunderstood the problem. Two people will stop each other from wasting many hours this way. One or two such insights can justify the entire session.

Pair programming is also constant code review. You get to discuss and and explain the design at the most optimum moment, when it is being written. Alone, you might get ninety-five percent of a design perfect, so that no one could possibly improve on it. But that stupid five percent could have been avoided by almost anyone you pull in from the hallway. You could have avoided it yourself on Tuesday, but today is Thursday, and you are using a different part of your brain. Two people are less likely to have the same blind spots.

Each programmer has a high tolerance for complexity in certain types of code. Certain strange idioms are second nature to you, but to no one else. You won't know for sure, unless someone is sitting next to you asking "What the heck is that?" Then you'll break the one clever line into several readable lines, and move on.

You'll like your work better, others will like your work better, and you'll get more done. That should be enough reason to give pair programming a try. Maybe it won't work for everyone, or everyday. Don't force yourself or others to participate. You must be relaxed and receptive. As with any new skill, it works better with practice. Try with different partners and different problems. If you find yourself staring blankly at the screen, then surely you can't do any worse with someone else in the room. Try it right then.

What if your programmers work in different cities? Try using an instant messenger, such as IRC, Jabber, or Yahoo's. These allow you to pass files and snippets of code back and forth. You can archive your conversations. Netmeeting will also let you pass an editor back and forth.

Bill Harlan, March 2001


Return to parent directory.