Pair programming goes against the rugged individualism that we’ve been indoctrinated into from the beginning, through school (where we succeed or fail on our own, and working with our neighbors is considered “cheating”) and media, especially Hollywood movies in which the hero is usually fighting against mindless conformity[19]. Programmers, too, are considered paragons of individuality – “cowboy coders” as Larry Constantine likes to say. And yet XP, which is itself battling against conventional thinking, says that code should be written with two people per workstation. And that this should be done in an area with a group of workstations, without the barriers that the facilities design people are so fond of. In fact, Beck says that the first task of converting to XP is to arrive with screwdrivers and Allen wrenches and take apart everything that gets in the way.[20] (This will require a manager who can deflect the ire of the facilities department.)

The value of pair programming is that one person is actually doing the coding while the other is thinking about it. The thinker keeps the big picture in mind, not only the picture of the problem at hand, but the guidelines of XP. If two people are working, it’s less likely that one of them will get away with saying, “I don’t want to write the tests first,” for example. And if the coder gets stuck, they can swap places. If both of them get stuck, their musings may be overheard by someone else in the work area who can contribute. Working in pairs keeps things flowing and on track. Probably more important, it makes programming a lot more social and fun.

I’ve begun using pair programming during the exercise periods in some of my seminars and it seems to significantly improve everyone’s experience.