Pair programming

Pair programming is a software development practice in which two programmers work together at a single workstation, collaborating on the same design, algorithm, code, or test. One person, the driver, types and controls the keyboard, focusing on the tactical work of producing the code line by line. The other, the navigator, reviews each line as it is written, thinks about the broader design, spots errors, and suggests alternatives. The two switch roles frequently, often every 15 to 30 minutes, so neither stays fixed in one mode for long.

The practice is most strongly associated with Extreme Programming (XP), which takes the conventional best practice of peer review to its extreme by making review continuous rather than a separate, after-the-fact phase. Pair programming is also embraced by the software craftsmanship movement as a way for developers to learn from one another and raise the quality of their work through deliberate, shared practice.

A closely related variant is strong-style pairing, conceived by Llewellyn Falco. Its golden rule is that, for an idea to go from your head into the computer, it must pass through someone else’s hands. This forces the driver to articulate intent and the navigator to engage actively, rather than letting one person silently dominate. Strong-style pairing inspired mob programming, which extends the same idea to the whole team.

Benefits

Proponents argue that pair programming produces several benefits.

  • Higher code quality. Two minds catch defects and design flaws as the code is written, rather than after a separate review phase.
  • Continuous review. Feedback happens inline, eliminating the lag between writing and inspection.
  • Knowledge sharing. Working together spreads understanding of the codebase across the team, reducing bus factor risk and onboarding new members faster.
  • Focus. The presence of a partner makes it harder to drift into distraction or yak shaving.

Criticisms

Pair programming is not universally practiced or accepted. Common criticisms include the following.

  • Cost. Two people on one task doubles the apparent labor, though proponents argue that quality and throughput gains offset the cost.
  • Fatigue and strain. Sustained pairing is mentally tiring, and interpersonal friction, hygiene, or scheduling mismatches can make it unpleasant.
  • Disruption of maker’s schedule. Pairing demands long blocks of uninterrupted shared time, which is hard to protect in a meeting-heavy environment.
  • Skill imbalance. A large gap in experience can turn pairing into a lecture rather than a collaboration, frustrating both parties.

See also

References