Pair Programming ("pairing") means that every line of code (test code or production code) is written by two programmers at a single computer. At any given time, one of them is actually typing at the keyboard (the "driver"), and the other serves as "navigator." They work as peers, sharing insights about the code as they work together.

The driver definitely has the "worm's eye view." The driver concentrates on the specific task at hand, working in the addictive rhythm of TDD: write a little test, write a little code to get the test to pass, do a little refactoring if called for, move on to the next task. This style of programming is completely engrossing.

The navigator, less engrossed in the code, has the bird's eye view. He or she thinks about whether the current code is duplicated elsewhere, or whether the code is getting smelly. The navigator spots typos and thinkos, recommends that the pair commits their source to the repository, recommends simpler designs, asks queries of other pairs on the team, and recommends bio breaks. He or she gently reminds the driver to write tests before writing production code, should the driver lapse.

The navigator thus serves vital roles that drivers sorely need, keeping things on process and humming along smoothly. When the driver gets stuck or tired, or when the navigator gets a powerful itch to drive for awhile, the two switch roles.

This is how the pair keeps working at maximum speed. As they work together, they grow equally intimate with their code. Either one could explain its workings to anyone else. Thus knowledge is spread.

If one of the programmers is more experienced or knowledgeable about specific technical areas or about programming in general, that veteran passes their knowledge systematically to the less-knowledgeable programmer (who should be peppering the veteran with questions). Thus, too, knowledge is spread.

In pairing, novice programmers can be vital. They are more likely to see the code for what it actually is, instead of what the veteran is accustomed to seeing. Veterans have habits, not all of them healthy, and talented novices can spot flaws in them. This questioning of tradition is a healthy part of pairing. Better ways are introduced, tested, and adopted. Thus, again, knowledge is spread.

Every day in an XP team, you might end up pairing with someone new. You learn things about the system under development that your new partner just learned with his last partner, and you spread the lessons you and your last partner learned. Thus (repeat after me), knowledge is spread.

Contrary to what you might think, pair programming is actually more productive per programmer-day than working alone, for reasons alluded to above. A smoothly-running pair produces cleaner, simpler code, with fewer defects, and produces it a bit faster than the same two programmers working alone.

Yes, it takes discipline and courage for everybody to pair all the time. Sometimes shy people will be paired with chatty people. Sometimes experts will be paired with novices, or novices with each other. Yes, some people will really prefer not to pair. But these are all problems that can be overcome, and should be overcome anyway, because they hide deeper inter-personal problems.

If your expert programmers are not patient enough to work closely with novice programmers, then they may not be doing you any favors when they deal with customers, either. If your shy people cannot fend well with chatty programmers, then they are probably a bit too shy with your customers also.

If your programmers are not sharing knowledge with each other all the time as they work, you are going to have big problems, sooner or later. You will have islands of knowledge, and a low truck number. It will take too long to get new team members up to speed. People will start writing duplicate code again, unwittingly.

Be courageous as an organization, and choose to transition from no pairing to pairing all the time. Identify the potential inter-personal problems, and help people overcome them. The benefits far outweigh the short-term costs. This is another classic example of trading a little short-term productivity for an enormous increase in long-term production capacity.

For more information on Pair Programming, see the excellent resources that Object Mentor has assembled at pairprogramming.com

[Next Practice]