Section 5.5. Pair Programming | Applied Software Project Management

5.5. Pair Programming

Pair programming is a technique in which two programmers work simultaneously at a single computer and continuously review each others' work. Although many programmers were introduced to pair programming as a part of Extreme Programming (see Chapter 12), it is a practice that can be valuable in any development environment. Pair programming improves the organization by ensuring that at least two programmers are able to maintain any piece of the software. Pair programming also helps programmers' professional development, because they learn from each other.

Pair programming is like having a continuous code review, without the extra time or effort of holding individual code reviews. It encourages a redundancy among the team members, and everyone is cross-trained on various parts of the code. Junior people can more quickly learn directly from senior people when they are paired together. While it may seem that assigning two people to a single programming task could be inefficient, in fact, productivity often increases. It takes somewhat less time to perform each task, as there are often gaps where one person is "tapped out" and the other can take over. More importantly, the resulting code is of very high quality, so there are far fewer mistakes to go back and fix.

One useful benefit of pair programming is that people tend to write better code when they know that someone else will be reading it. They cut fewer corners, spend more time making the code readable, are more likely to include comments where necessary, and refactor more often.

In pair programming, two programmers sit at one computer to write code. Sometimes they share a single keyboard and mouse, although it is possible to get special hardware or cables that allow each programmer to have his own. Generally, one programmer will take control and write code, while the other watches and advises. But different pairs of people may discover their own dynamic: for example, some pairs will take turns at the keyboard, while others will designate one person as the typist (if one person types significantly faster than the other).

It's straightforward to implement pair programming in any development teamjust choose two programmers who are willing to give it a shot, and have them work together at the same computer. However, it's important to remember that, like any programming technique, pair programming is a skill that improves with practice. Some benefits can be realized almost immediately, but there is no substitute for years of experience. But, like any other programming skill, the only way to get experience is to practice.

While efficient pair programming is a skill that requires practice and patience, there are some useful tips that make its initial adoption easier. People will be less resistant to a change if their first experience with a new technique is positive. One way to help guarantee this is to pilot pair programming on a low-risk portion of code. The project manager should choose one where the scope and requirements are well understood going into the project, and where success is easily measured. Both members of the pair assigned to work on it should be people who have done similar projects in the past. These circumstances can provide an opportunity for an easy win, which in turn will increase the programmers' confidence in the technique.

Some teams have found that pair programming works best for them if the pairs are constantly rotated; this helps diffuse the shared knowledge throughout the organization. Any two programmers can potentially make a well-functioning pair, no matter what their relative experience. Some people have found that it helps to choose pairs that include both a senior person and a junior person. This will make it easier for the communication to fit into an existing pattern (mentor and tutor, roles that both people are already used toalthough this is not necessarily how all senior-junior pairs will interact). Often, a junior team member will ask a seemingly "naïve" question about the code that turns out to identify a serious problem. This is especially common with problems that the senior member has been living with for so long that she no longer notices them. Sometimes, the extent of a code problem only becomes clear when it is explained to somebody else.

Pair programming is not for everyone. It is difficult to implement pair programming in an organization where the programmers do not share the same 9-to-5 (or 10-to-6) work schedule. Some people do not work well in pairs, and some pairs do not work well together. The project manager should not try to force pair programming on the team; it helps to introduce the change slowly, and where it will meet the least resistance. Some programmers will argue that assigning two people to one task is a waste of time, claiming that two people can get twice as much work done if they work separately. While this may seem true at first glance, the pair will introduce far fewer defects; it may require more man-hours to do the programming, but it will reduce the amount of time spent on bug-fixing and maintenance. However, this may not convince some stubborn programmers. In this case, an effective way to introduce this technique is to begin with the people who are more excited about the idea. Their success can help to convince the stragglers of the value of pair programming.

Note: More information on pair programming can be found in Extreme Programming Explained by Kent Beck (Addison Wesley, 1999).