Pairing
What is it
Pair-programming or pairing is when 2 individuals are working on a task in a session.
One is “driving”, i.e. implementing the task (coding, designing, testing), the other is “navigating” — helping with instructions.
When done in person, a single computer is used.
Remotely, the driver is sharing their screen with the navigator, e.g. with Google Meet or Tuple which allows the navigator to draw and type as well.
Roles are switched every some time (15 minutes, 30 minutes, 1 hour…) or after finishing an intermediate goal.
Who: engineers, designers, product managers, tech lead, architects, testers…
Mob programming / mobbing / mobramming is when more than 2 individuals are in the session.
This technique is at least 70 years old — Fred Brooks, author of The Mythical Man-Month [Brooks 1975]:
Fellow graduate student Bill Wright and I first tried pair programming when I was a grad student (1953–1956).
We produced 1,500 lines of defect-free code; it ran correctly first try[Williams and Kessler 2003]
Isn’t it wasting resources?
If 2 people can work on 2 different tasks, why on earth would I place them both on the same task? Will they finish it in half the time?
They may or may not.
Even when working alone, we get stuck, we might need breaks or “clearing our head”.
If it were real resources like machines, we would use 2 to double our output. Knowledge workers are not resources in a Tayloristic world.
So why? Is it another hype?
The pain
Take a common development process. Let’s take a look at the starting point of implementing:
Alice implements and creates a branch and a pull request [Alice Context Switch] →
🕙 [Bob Context Switch] Bob reviews and gives feedback [Alice Context Switch] →
🕙 [Bob Context Switch] Alice fixes and resubmits [Alice Context Switch] →
🕙 [Bob Context Switch] Bob reviews and approves [Alice Context Switch] →
🕙 [Bob Context Switch] Alice merges and deploys
We see several pain points here:
- There are at least 8 context switches, each costs ~15 minutes to go back in to the mental state. Imagine cases of more back and forth, or late code reviews which are more expensive
- The piece of work, or its potential value takes long to finalize
- Team members are pressured to both finish “their own” tasks and to review others’ work
- Reviewers are not always familiar with the domain or task, leading to a shallow review (notorious LGTM 👍)
- The “pick up time” — the time until a review starts is causing further delays. It is evident in DORA metrics — the lead time (time from first commit to deployment) is higher and the number of deployments is lower
- The waste and pain of waiting for a review is so high, that there are software tools that offer reminding others to review, and estimating the necessary review time based on AI, just to engage them
- Things get worse when there is a separate “tester” and “deployer” role, which are additional handovers, idle time for a given task and more context switches
The mitigation
Pairing: Alice and bob work on the task together: they implement and push to main.
That’s it.
Welcome to trunk-based development 🎉
Remember that pull requests were initially designed for (distributed) open sources development.
Let’s look at the benefits in detail:
- No context switches, keeping the same mental state
- The piece of work (potential value) takes shorter to finalize
- No pinging other members for review
- The shorter cycle time and higher number of deployments are evident when tracking DORA metrics and no pick-up time for code reviews
- No need to nudge members to review after the initial request
- Avoiding issues with code review comments (this is a whole separate topic):
> Cannot guess the tone of written communication, e.g. “Go ahead if you think it’s good.”
> Long threads
> Non-constructive comments like “this is bad”
> Not explaining why “please change to one-liner”
> Superficial code reviews, as was well expressed in the joke:
5 lines of code → 10 comments
500 lines of code → “looks good to me”
> and many more… - Holding each other accountable for methods and conventions:
There is much more added value
- Expedited knowledge sharing about the domain
- Expedited growth of skills (BE, FE, IaC…), techniques, languages, frameworks, debugging, observability…
- Business continuity in case of absences and departures (high bus factor)
- Rapport and trust built in the team
- Facing problems together, more than one way to solve a problem
- Designer and PM feel included when paired with
- Higher diversity and inclusion
- Fast onboarding of new-joiners
- “I wish someone had told me decades ago, that the fastest ways to learn is pairing with somebody else frequently” — a veteran colleague
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.
eXtreme Programming and Flexible Processes in Software Engineering XP2000 by Alistair Cockburn and Laurie Williams
Compliance
“Sounds great, but we’re SOC-2 compliant, which means we must have pull requests with documented approvers. We cannot do that!”
Actually, yes you can!
Trunk-based development is compliant when all commit messages additionally include the ticket number (link to the requested change) and the person pairing.
Downsides
- Coordinating who pairs with whom (but need to only manage work of N/2 team members)
- Re-coordinating pairs after finishing a task
- A tool to share the screen
- Coordinating bio breaks and lunches
- Time zones must be close. Having hours of work in isolation is missing the point
- Resistance of individuals (preference of own comfort over productivity):
- High Cs prefer to show finished work
- Might be more energy draining for introverts (having video camera off helps)
- Feeling of invading the “personal space” and watching every movement
- Preference to listen to music while working
- My daughter might call me
- Requires empathy and alignment on the pace
- Still need pull requests in some edge cases (cross-team work, opinion of a domain/technology expert before having enough domain or technology knowledge)
How to implement
- Explain the benefits and paint the bright future picture
- Prepare to answer questions and resistance
- Can we pair only on the “hard parts” / “the design” / “that function”?
- If it’s so good, why not managers?
- Allow pushing to the main branch
- Pick a tool for sharing screen for remote people (e.g. Tuple)
- The pair designs, implements, evolves, tests and deploys together
- Talk during pairing — driver and navigator (who continuously reviews)
- Others may join or be invited ad hoc
- Give autonomy to decide the duration of each driver/navigator
- When done, split pair to help others or pick new work
- Mix pairs to prevent the same people always pairing: friends or not, varying seniority, different expertise (BE, FE, Infrastructure, mobile…)
- Consider move a resistant member to a team that is already pairing
- Let teams discuss and improve how they pair in retrospectives
What helps
- Managers and directors not spying on pairing
- Existing psychological safety, trust and rapport
- Allowing humor and “wasting” social time during pairing
- Good communication (language, intent, clarity)
- Pairing also on support requests, spikes, incidents, bugs and hackathons
What hinders
- Not holding each other accountable for pairing
- Dominant and dogmatic members; “my way or the highway”
- Setting DORA or other metrics as goals to achieve
Appendix — history of pairing
From the Agile Alliance:
- The Pair Programming origin is uncertain. According to the Agile Alliance, it dates back to the “Dynamic Duo” concept observed by Larry Constantine in the 70’s, but some people suggest it might have been practiced way before in the mid-50’s by Fred Brooks.
- 1992: “Dynamic Duo” is the term coined by Larry Constantine, reporting on a visit to Whitesmiths Inc., a compiler vendor started by P.J. Plauger, one of the implementors of C: “At each terminal were two programmers! Of course, only one programmer was actually cutting code at each keyboard, but the others were peering over their shoulders.” Whitesmiths existed from 1978 to 1988.
- 1993: “The benefits of collaboration for student programmers” by Wilson et al. is one early empirical study indicating the benefits of pairing for programming tasks specifically. Posterior studies are more abundant and driven by the desire to “validate” pair programming after it had already gained popularity through Extreme Programming.
- 1995: the pattern “Developing in Pairs” is given a brief description, in Alexandrian pattern form, in Jim Coplien’s chapter “A Generative Development-Process Pattern Language” from the first patterns book, “Pattern Languages of Program Design”.
- 1998: in “Chrysler goes to Extremes”, the earliest article about Extreme Programming, pair programming is presented as one of the core practices of the C3 team; it is later described formally as one of XP’s original “twelve practices”
- 2000: (or earlier) — the roles of Driver and Navigator are introduced to help explain pair programming; the earliest known reference is a mailing list posting; note however that the reality of these roles has been disputed, for instance, Sallyann Bryant’s article “Pair programming and the mysterious role of the navigator”
- 2002: “Pair Programming Illuminated”, by Laurie Williams and Robert Kessler, is the first book devoted exclusively to the practice and discusses its theory, practice, and the various studies up to that date
- 2003: an anonymous article on the C2 Wiki describes Ping-Pong Programming, a moderately popular variant that marries pairing with test-driven development.
- 2015: James Coplien publishes Two Heads are Better Than One which provides an overview of the history of Pair Programming that traces its origins back to the mid 1980s if not before.
