Pair programming is a style of programming in which two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, or test. Pair programming has been practiced sporadically for decades [Williams and Kessler 2003]. However, the emergence of Agile methodologies and Extreme Programming (XP) [Beck 2005] in the late 1990s brought the pair programming practice to more recent prominence.

With pair programming, one of the pair, called the driver, types at the computer or writes down a design. The other partner, called the navigator, has many jobs. One of these is to observe the work of the driver—looking for tactical and strategic defects in the driver’s work. Some tactical defects might be syntax errors, typos, and calling the wrong method. Strategic defects occur when the driver’s implementation or design ultimately will fail to accomplish its goals. The navigator is the strategic, long-range thinker of the programming pair. Because the navigator is not as deeply involved with the design, algorithm, code, or test, he or she can have a more objective point of view and can better think strategically about the direction of the work. Both in the pair are constant brainstorming and chatting partners [Wray 2010]. An effective pair will be constantly discussing alternative approaches and solutions to the problem [Vanhanen and Korpi 2007], [Williams and Kessler 2003]. A sign of a dysfunctional pair is a quiet navigator. Periodically, the driver and the navigator should switch roles. On a software development team, team members should pair program with a variety of other team members to leverage a variety of expertise.

The name of the technique, pair programming, can lead people to incorrectly assume that software engineers and others on a software development team pair only during code development. However, pairing can occur during all phases of the development process—in pair design, pair debugging, pair testing, and so on. Programmers could pair up at any time during development, in particular when they are working on a complex or unfamiliar problem. Additionally, a product manager may pair with a user interface designer to collaboratively develop the user experience. A tester and a developer may pair during the creation of automated tests. In short, the side-by-side collaboration style of pair programming can be done by many in the team, at all phases of development.

This chapter starts with a brief history of the use of pair programming. Then, I provide information on the use of pair programming in industry and in academia, respectively. Following that, I discuss distributed pair programming, which is the use of pair programming when the programmers are not co-located. Finally, I present the challenges in transitioning to pair programming.