Key practice in effective product development culture.
—
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:
- Understand the problem;
- Understand the existing code;
- Design the change;
- Type it in;
- Validate that the change works;
- Clean up;
- 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:
- Write code;
- Submit code for peer review;
- Wait for a reviewer to respond (sometimes days);
- Reviewer adds comments — asynchronous back-and-forth (sometimes days);
- Fix code if necessary
Typical sequence for synchronous, continuous review when pair (or whole team) programming:
- 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.
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.
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.
