Pair Programming Basics

The basic idea behind pair programming is that two heads are better than one ”that a pair of programmers working together will produce a higher quality product than a single programmer. So, for production code, XP mandates that everyone on the team program in pairs. Pairing up is an effective way of catching errors and identifying ways to further simplify the code. To facilitate collective ownership of the code, XP encourages people to move around and switch partners frequently. It s kind of like square dancing : Change your partner! every couple of hours. And, of course, in XP all the pair programming goes on in a single room.

On the surface, pair programming sounds like a great idea. It s been well known since the ancient days of punched cards that having another programmer look at your code can help to catch bugs . In some circumstances it can undoubtedly work tremendously well. Just as obviously, you ve got two programmers doing the work that one programmer was previously doing if everybody has to pair program. Some research studies claim there is no significant decrease in productivity (as we discuss later in this chapter).

Problems with pair programming can arise because of several factors, including

• Social dynamics

• Lack of privacy

• Lack of quiet thinking time

• Ergonomic issues

Pair programming is necessary in XP because it compensates for a couple of practices that XP shuns: up-front design and permanent design documentation. Coding in pairs can be seen as a compensatory practice that theoretically makes up for the fact that the programmers are (courageously) making up the design as they write the code.

There is certainly no problem with people working in pairs if they want to work that way. So it makes no sense to prohibit pair programming. However, changing it from a voluntary practice to a mandatory one makes quite a difference.

People You'd Least Like to Pair With (No. 48)

Pair programming is definitely not for everybody, as Doug relates here.

Having a number of years of programming experience, I place a pretty high value on peace , quiet, and space to think in. According to a study from IBM s Santa Teresa Laboratory, ^[5] putting programmers in private offices with doors that closed instead of cubicles resulted in a huge boost to productivity. So the idea of all the programmers in a big, noisy room seems like it would be a huge detriment to productivity. It would figure to drive many people nuts.

I ve also worked with some incredibly talented programmers who would have been awful to pair with. One who comes to mind is hypoglycemic and has a tendency to get upset very easily when his blood sugar drops . He s a brilliant programmer who produces prodigious amounts of code that s always efficient and well structured. He and I worked very well together but I would never dream of sharing a desk and a keyboard with him. And I d resist any process that wouldn t allow me, as a manager, to make use of his skills. So I would never mandate pair programming.

 

I Can t Code Alone . . . Cause I Need My Pair

(Sing to the tune of Ticket to Ride by The Beatles)

I guess I d better go home
It s time to go play, yeah
That pair programmer I had
Called in sick today, yeah

I can t code alone
Cause I ve tried
Gotta have my pair by my side

I can t really write any code
Cause I need my pair
Cause I need my pair

When I m refactoring code
He always sits right, always sits right by me
When we re runnin our unit tests
He always sits right, always sits right by me

I can t code alone
Cause I ve tried
Gotta have my pair by my side

I can t really write any code
Cause I need my pair
Cause I need my pair

^[5] Gerald M. McCue, IBM s Santa Teresa Laboratory ”Architectural design for program development, IBM Systems Journal ( http://www.research.ibm.com/journal/sj/171/ibmsj1701C.pdf), vol. 17, no. 1, 1978.