Key practice: pairing / whole-team programming

Jason Yip
3 min readAug 13, 2023

--

Key practice in effective product development culture.

Prompt: “Create an abstract image representing pair programming”

Pair programming is two programmers working together on the same problem at the same time.

NOTE: Although the Agile Alliance includes sharing a single workstation as part of the definition, I don’t consider this required. For example, remote pairing and head-to-head pairing (pairs face each other on their own machines).

Whole Team programming (aka mobbing or ensemble) is a team of people working together on the same problem at the same time.

What problems does pair (or whole team) programming solve?

The constraint is not typing speed

Typical sequence for programming:

  1. Understand the problem;
  2. Understand the existing code;
  3. Design the change;
  4. Type it in;
  5. Validate that the change works;
  6. Clean up;
  7. Repeat

Most of the constraint in programming speed tends to be around understanding and designing, not typing. Adding additional brains can help accelerate understanding and designing.

Continuous review

Typical sequence for asynchronous code review:

  1. Write code;
  2. Submit code for peer review;
  3. Wait for a reviewer to respond (sometimes days);
  4. Reviewer adds comments — asynchronous back-and-forth (sometimes days);
  5. Fix code if necessary

Typical sequence for synchronous, continuous review when pair (or whole team) programming:

  1. Write code and review it immediately.

Balancing peaks and troughs

Energy levels naturally ebb and flow when programming. When, when one programmer’s energy levels ebb, the pair can pick up the slack and vice versa.

2x2 matrix for energy up and down for pair member A and B. When B is up and A is down: B drives; when A is up and B is down: A drives; when both are down: “Let’s take a break”; when both are up: Back-and-forth “Woohoo! We’re in the zone!”
Your pair can pick up the slack when your energy level is down and vice versa.

Resilience through diffusion of knowledge

If only one person knows something, any work that depends on that knowledge stops the moment that person goes on vacation, get sick, leaves the company. Pairing and pair rotation spreads knowledge which reduces risk.

Pairing to spread knowledge and reduce key person dependency

Rapid onboarding

The fastest approach I’ve ever seen to onboard someone new is pairing and regular pair rotation. The new person very quickly understands what knowledge is relevant or not, and what unspoken assumptions and practices are in play.

I’ve seen this help reduce the impact of Brooks’ Law (“Adding manpower to a late project makes it later.”) though not entirely.

Key assumptions

  • Growth mindset. People need to feel safe and accept the vulnerability of others being able to see their capability gaps.
  • Team performance is more important than individual performance, which means people are willing to adjust to what works better for the team despite individual preference.

See also

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl