Why pair? Isn't it inefficient and boring? On the contrary, pairing, when done correctly, is not only extremely productive, it's a lot of fun. If you're not more productive and enjoying yourself to a greater extent while pairing, it's not because pairing doesn't work, but because you aren't really pairing. I've discovered an excellent model for pairing which helps me to pair correctly, but first, it's important to understand the difference between 'true' pairing and 'false' pairing. The easiest way to delineate it is by laying out the purposes that true pairing fulfills.
XP throws out the idea of doing a Big Design Up Front, and instead pushes design to where it really happens anyhow: at the keyboard. Without pairing this design happens alone, and occasionally is critiqued after the fact in a code review. BDUF, which is supposed to leverage everyone's knowledge and put it all together into one design, ends with almost every important design decision happening solo. Pairing, on the other hand, brings two people into each design decision. In the end, design within a pair is more than twice as effective as that in traditional development, because as pairs switch up, knowledge about the design decisions that have been actually implemented is spread throughout the team. System's built with this method of design will end up with a consistency lacking in any BDUF project.
Some might shy away from pairing because they don't want to stare over someone's shoulder correcting syntax errors. While a pair will catch the occasional syntax error, the compiler does a fine job catching the rest. The more important job of the pair is to make sure the code is readable when it's finished. Stephen King wouldn't imagine publishing a book without having his editor read it first. While the editor will catch capitalization, spelling and grammar errors, he's much more concerned with whether he can understand and appreciate the book. In the same way, each of those pairing is trying to understand the code that the other produces, and improve it if he can't. Since two people have read and comprehended the code, the odds are more than double that the next programmer who comes across it will also understand.
One of the first objections raised to putting all of the programmers in the same room is that it will be distracting. In traditional development, distraction would definitely be a problem. As a matter of fact, it is a problem. Toys, the Internet, coworkers, food, and many other things can easily distract developers from their work. The solution, though, is not to put the developers into a sterile environment and restrict their activities (a solution tried by large companies). Neither is the solution to let it run rampant in the hopes that the programmers will get tired of distraction, and thus do more work (a popular path for smaller companies). The definition of a distraction is something that's more compelling than what is currently being done, so the best possible solution is to make development the most compelling activity. Pairing (at least, pairing done correctly) accomplishes this goal by making programming an extremely interactive process. It can be quite intense, and often results in more productivity in shorter workdays. It balances itself from burnout, though, because instead of agonizing over whether or not he ought to take a break, a programmer simply asks his pair, "Want to take a break?" When they're overwhelmed or need to clear their thoughts, they do, and they concentrate better the rest of the time.
The principles in XP are quite simple, and there aren't that many to remember. Yet often, programmers stray from the path and do anti-XP things, often without even realizing it, not because the principles are complex, but because they're so radical. They go against both trained habits and human nature. Pairing is critical to XP because it works to keep everyone on process. Two people are present to remember the concepts, and when to apply them. A friendly competition often goes on as each programmer tries to catch the other missing an XP principle and chastise them for it. Instead of XP being an unbearable set of commandments impressed on unyielding subjects, it becomes a framework that holds the team together and helps them reach their goals.
Pairing raises the truck number, that is, the number of people that have to get hit by a truck before the project is hosed. Everyone gets a chance to touch each part of the system, and if they have to venture that way again, it's not completely new. XP throws out code ownership, and pairing allows this not just through sharing understanding but also through sharing ownership. No one can claim a piece of code as their own, because it wasn't written solely by them, but rather with a pair. It's like a father or a mother claiming 'ownership' of their child, when both of them were quite necessary for its conception.
I've had many pairing experiences that failed on at least one, if not all of the points above. The design produced was heinous, the code was illegible, myself or my pair was distracted most of the time, we broke principle after principle, and afterward one of us felt too much ownership of the code. It's quite possible to 'maverick' (our teams term for programming alone) with someone else watching. How do we pair in a way that fulfills the purposes of true pairing? The key, I believe, is that true pairing is not like reading the comics over someone's shoulder and laughing at the punch lines before they get to them, but rather like having an interesting conversation at a fabulous party. A name I've used to distinguish true pairing from its doppelganger is that of 'conversant pairing.'
I, personally, was born quite without social skills. Due to this, how to have a good conversation with another person has been (and still is) an intense course of study for me. I'm finding that the principles at work in a good conversation apply equally well to the practice of pairing. Also, just like the art of conversation, while some have greater natural talent for it, everyone can improve in their pairing skills.
Almost always a conversation begins with a question. My father often drives me nuts because he's so good at the skill of asking questions that it's often impossible to get him to leave a place as his conversation goes on and on. Questions are a constant part of a good pairing session. Usually they start with "What's the task?", continue with, "What do you think about _____?", and end with "Is that everything that needs to be done?" Asking and answering questions is not just for the sake of making noise, either. Many times a vocalized explanation of what is being thought about will bring about a new understanding of the problem or its solution. When (occasionally) I find myself without a pair, I unconsciously talk to myself about what I'm thinking. Having a person actually listening is even better, though, because then they respond (usually with "Have you lost your mind?") and I get feedback on my thoughts.
Nobody likes to carry on a conversation with someone who isn't interested in what they have to say (or in answering any questions). An extreme example (no pun intended) is a coworker of mine who had someone at a local users group ask him what he did. Before he could even get two words out of his mouth, the original asker of the question had turned around and started talking to someone else. That put a quick end to the conversation. It is critical that both members of a pair maintain a high degree of interest and engagement with the problem at hand. There is an automatic feedback loop here, because as interest is shown, the conversation gets more interesting, meaning that an even greater level of interest is shown, etc. Even if the task is the most boring thing ever encountered, there is sure to be something stimulating buried in it. If not, then fake it. Often genuine interest will follow (due to the feedback loop).
I often find myself feeling rushed while having a conversation. Instead of sitting back and enjoying the ebb and flow of it, I'm rushing to get it over with as soon as possible. Don't hurry the pairing experience. When a question comes up, take time to answer it fully. 'Haste makes waste' is quite true. Sometimes it's easy to get so caught up with trying to get a job accomplished that the forest is missed for the trees. Moving too fast leads to situations where extra complexity is included in the code because a rushing pair missed a much simpler solution. This is not to say that we should stop and have a ten-minute discussion about every variable name; balance and judgment are definitely required.
The most interesting conversations usually center on some controversy or another. Politics, while being a contentious topic, is often the subject of very interesting discussions at parties. It sure beats the weather. Likewise, pairing is much more exciting if the pair doesn't fall into the habit of just agreeing with the first suggestion proposed. Take up sides, and then duke it out. Two important points: first, use humor liberally when doing this. Keep it light, which is to say, don't get too serious. Second, remember that the goal is to produce the best code possible, not to be right. Humility goes a long way here.
Knowing something about the one you're talking to goes a long way towards keeping the conversation interesting and enjoyable for both parties. A conversation is not just about sharing knowledge, but more importantly, it is about building a relationship. Pairing is much easier when you know something about the person next to you. While you wait for tests to run, find out about their education. While integrating, ask them about their family. Any interesting conversation roves over many topics, and spending all day next to another person will be much more enjoyable if the interaction extends beyond the code at hand. Many software development processes treat programmers as glorified machines, churning out a set product from a specification. XP, and pairing, bring the 'human touch' back into software, emphasizing the importance of each individual's uniqueness, and their ability to contribute to the goals of the team.
As I write these ideas down, they seem almost self-evident, if not blatantly obvious. The question is if they're so obvious, why have I had so many sub-optimal pairing sessions? For the same two reasons I have lackluster conversations: I fail to follow the principles, and/or I succumb to an anti-principle (or hindrance). What are the hindrances to conversant pairing?
One is working with someone at a significantly different level of expertise. If I pair with a much better programmer, I tend to back off and keep quiet, content to just sit back and enjoy the ride. If, on the other hand, I pair with someone with a good deal less experience, I'm tempted to sail along without explaining what I'm doing and getting their input. The root of the lack of conversation in both of these scenarios is pride. In the first one, I'm too proud to open my mouth and potentially ask a stupid question or make a stupid suggestion. In the second scenario, my ego tells me that I don't need the input of the other developer, because I know so much more what needs to be done. Both of these are the same problem, seen from opposite perspectives. The junior developer needs to realize that he'll never learn unless he asks questions and makes suggestions. The senior developer must remember that he needs to talk about what he's doing because it organizes his thoughts and he might be surprised with an insightful suggestion.
Another common hindrance to conversant pairing is overdoing the controversy to the point that it becomes arguing. Controversy is about searching out the best solution through taking up and defending sides. Arguments are about ending up on top. At the end of a controversy, both sides have almost always compromised, and the solution is better than either side's original position. It is very important to detach oneself from the outcome and embrace it with a whole heart, whether it was your idea or not. When controversy begins to move towards argument, and either pair feels objectivity has been lost, or just doesn't know which is better, a third party should be pulled in from the team and their opinion garnered. This may result in one of the current options being adopted, or a third option may be suggested which is better than either of them.
Finally, anti-social behavior is another wide categorization of hindrance. It includes refusing to pair in the first place, being personal in the humor leveled at others, forgetting to put on deodorant in the morning, talking all the time, not talking at all, eating garlic for breakfast, and even falling asleep when not driving. In many cases, the one being anti-social is not even aware of it, and it falls to their pair to carefully inform them of it. Beware, though, that what you view as being anti-social behavior (such as pestering you with questions) might simply be an attempt to correct for your neglect of a principle (not discussing decisions before you make them). A lot of humility is needed in both pointing out and dealing with anti-social conduct.
I'm sure that there are other models that can be applied to pairing, but the conversation is the best one I've found yet. One of the coolest things about pairing is that you never stop learning. Each person I pair with teaches me something new each time I pair with them. Everything in this paper I've learned from real pairing experiences, and from those with whom I've paired. As time progresses, I know that I'll learn more not only through pairing, but also about pairing.