Skip to Content

Pair Programming

Last modified by chrisby on 2024/05/22 09:34

Two or more developers collaborate on the same workstation and write code together.

Benefits

  • Training: The best way to teach people new skills. Pairing with beginners and new members of the project is especially useful to get them productive quickly.
  • Shared Knowledge: Not only code, but also knowledge should be collectively owned. If a team member is not or no longer available, other team members should be able to take over the task. It is your responsibility to train 1-2 other team members to take over your responsibilities when you are unavailable. Sometimes writing scripts and documentation can be a good supplement. This prevents the creation of knowledge silos.
  • Real-time Code Review: Fastest possible feedback. Because "two heads are better than one," there is better design, higher code quality, and fewer bugs.
    • Talking is cheaper than writing. Communicating about a problem in person and verbally is much more efficient than the process of writing emails or code reviews on GitHub. Problems are addressed later because it takes time to comment, wait, respond to comments, wait, respond to responses, etc. You also have to spend time getting back on topic and code after each wait. A fluid, real-time conversation has less overhead.
  • Increased Motivation: Developers usually find it more fun and enjoyable to incorporate pair programming into their work than to work alone all the time.

The cost of pairing is that two programmers focus on one task instead of two, but the benefits of pairing often outweigh this. However, some tasks are simply more efficiently done alone, which is why people usually do not pair all the time.

Guidelines

  • Pairing is Optional: Don't force anyone to pair.
  • Remote pairing is possible as long as both developers share the same code. Video conferencing is an option, or there are IDE's that allow real-time collaboration on the same code. This is less efficient than in-person pairing, but still much better than never pairing.
  • 50% Pairing: Spending half the programming time in pairs is a good guideline, although the actual value may vary depending on the situation and personal preference.
  • Spontaneity: Should be spontaneous and not planned.  Simply pair up when you feel the need and disengage when the need is satisfied. However, developers' preferred pairing or no-pairing times and schedules should be taken into account.
  • Pairing Session Duration: Ranges from a few minutes to an entire workday, depending on the situation. Often 1-2 hours.
  • Story responsibility is for individuals, not pairs. Stories take much longer than a pairing session. Developers should spend about half their pairing time on their own tasks and half on helping others.
  • Mob Programming: It is also possible for more than two people to meet to work on a problem.

Pairing Models

Here are some common models for pairing two programmers:

  1. No roles: Both share mouse and keyboard equally.
  2. Ping-pong: Person A writes test, person B makes test pass, person B writes test, person A makes test pass, and so on.
  3. Driver controls mouse and keyboard. Navigator observes and makes recommendations. Swap roles after a set time.

Exceptions

In my experience, pair programming is very efficient when a team of developers is working on a project full time and in the same room. This is the ideal software development environment. However, in some setups, this is simply not possible, e.g., in many open source projects, where people have completely different locations, time zones, availability periods, commitment to the project, and so on.