# Pair Programming

## Summary


A developer typically writes code alone. Pair programming is a practice in which two developers are paired together to jointly complete a task. The task could be software design, algorithm, coding or testing. The rationale is that two minds are better than one. If done correctly, pair programming yields better software faster and at lower cost. 

The pair share the same computer and possibly share a single keyboard. Each developer of the pair has a specific role but roles alternate often. Moreover, pairs are not static. Any two developers in the team could become a pair for a few hours. 

Pair programming is an essential practice in Extreme Programming. *Remote pair programming* is a specialization where developers can be at different locations. *Peer programming* is a term that's sometimes used when more than two developers are involved.

## Discussion

### Why should I adopt pair programming?

Among the many benefits of pair programming are faster onboarding of employees, better collaboration within the team, faster processing of pull requests (where code changes are reviewed and accepted), fewer bugs and ultimately better quality software. Pair programming also fits nicely into modern development pipelines such as CI/CD and truck-based development. 

Codebase is more consistent with coding guidelines due to collaboration. Solutions are better designed. Where problems are challenging, pair programming finds solutions faster. Due to increased social interaction, there's greater job satisfaction and higher productivity. 

Ultimately, pair programming is not just about writing code. It's also about planning the work, discussing ideas, clarifying viewpoints and coming up with better solutions. 


### What are the different styles of pair programming?

A few types of pairings exist:   

    + **Driver-Navigator**: One developer (driver) writes the code while the other (navigator) observes, asks questions, and thinks ahead. Driver explains her actions so that the navigator understands. Navigator is essentially doing a real-time code review.
    + **Driving School**: Aka *backseat navigator* or *strong-style*. Navigator takes more control and gives specific instructions such as "create a method" or "create a new file".
    + **Tour Guide**: The tour guide (driver) providing strategic and tactical thinking while also typing. The other developer is like a tourist, listening passively. In the long term, this style is not favoured since we learn better by doing than by observing.
    + **Ping-Pong**: Suited for Test-Driven Development (TDD) methodology. One developer writes the test while the other writes the code to make the test pass. Then they switch roles.
    + **Pomodoro**: Similar to ping-pong style but based on time limits. Pairing is for 25 minutes, followed by a 5-minute break. Then developers switch roles. After four such sessions, there's a longer 20-minute break. Breaks keep the sessions productive.
    + **Tag-Team**: Switching of roles can happen anytime for any valid reason.

### How is strong-style different from driver-navigator style of pairing?

In traditional driver-navigator style of pairing, the developer who gets an idea grabs the keyboard and takes the role of the driver. If the navigator doesn't know where the driver is going (due to lack of clear communication), the navigator may become bored and disengaged. 

In strong-style, the person with the idea takes the role of the navigator instead and guides the driver. Thus, both developers are actively involved. There's greater trust and knowledge sharing. 

In strong-style, the navigator gives high-level commands and the driver implements them at a low level. To ensure understanding, the navigator adjusts the level of abstraction. If the driver doesn't understand, the navigator provides more detailed commands. The driver trusts the navigator. The driver may sometimes work with partial understanding so that the navigator's flow is not broken. At a suitable pause in the flow, he may asks questions. It's been said of this style that, 

> For an idea to go from your head into the computer it MUST go through someone else's hands.


### What underlying mechanisms make pair programming effective?

In pair programming developers are required to discuss the code and ask questions. Asking the right questions can challenge assumptions and trigger new perspectives. Pair programming is therefore not just coding but also active learning. Vocalizing our thoughts helps us to arrive at the right understanding. 

As humans, we tend to focus on general ideas than fine details. As a pair, developers are likely to spot mistakes faster. No two developers will look at code the same way. This is aided by the assignment of specific roles, driver and navigator. The driver is thinking tactically while the navigator is thinking strategically and looking at the big picture. Code reviews are immediate. 

Pair programming avoids the bad practice of writing code by trial and error: if the code works, the developer may move on without checking for hidden flaws or bigger design problems. Pair programming allows developers to understand the problem fully before starting to code. 

Pair programming allows each developer to gauge the expertise of the other and even oneself. It's easy to claim expertise but when developers discuss and explain things, they become better at gauging each other's expertise. 


### How should novices and experts be paired together?

Pair programming is beneficial at all expertise levels because it's essentially a learned social skill. You're learning to work cooperatively with other team members. Where junior developers are involved, prioritize learning over productivity. 

It's common to identify the following pairings:

    + **Novice-Novice**: Novice developers may not be confident enough to tackle a challenging problem alone but they can do so more effectively as a pair.
    + **Novice-Expert**: Useful for training novices or quick onboarding of new developers to the project. The novice must ask questions and grow in confidence as a developer. The expert must be empathetic and explain the reasons for the code. The expert should not do all the work.
    + **Expert-Expert**: Useful when each expert specializes in different areas, such as frontend versus backend. They can pair up when a feature impacts both areas of expertise. One study showed that expert-expert pairing is less effective when both experts are familiar with the coding task and its solution.

### What are some best practices for pair programming?

Developers must have an attitude to share and learn from each other. Empathy, patience and openness are important traits. One developer should move only as fast as the other can understand. 

For better knowledge sharing and team collaboration, each developer must pair with different team members. However, where there's a personality conflict between two developers, such pairings must be avoided. Pairings can be changed daily, weekly or when user stories change. 

Pair programming can be demanding at times. Frequent breaks can help. It's also best not to do pair programming all the time or for every task. During pair programming, avoid interruptions from others. Between sessions, it's good to give and take feedback. 

To make participation easier, each developer has his own keyboard. Configure the system with key bindings and shortcuts that's comfortable to both developers. Create dedicated pairing stations uncluttered with personal items. 

Those new to pair programming can start with a simple task that can be completed in a short time. Minimize distractions during the session. Management should ask developers to try pair programming rather than forcing it on them. 


### What are the antipatterns in pair programming?

The navigator should avoid a few things: pointing out errors too quickly, giving too detailed low-level instructions, and perhaps not bringing a keyboard. 

The driver should avoid a few things: driving too fast that the navigator can't keep up, partially blocking the screen, not taking breaks, driving without listening to the navigator, and avoiding eye contact. 

Both developers should avoid a few things: distractions such as notifications or text messages, not swapping roles, not communicating with your partner, or giving up too early if you're just learning to code. 


### Could you share some case studies on pair programming?

Jensen (1996) reported from a study that pairs wrote 175 lines of code per person-month compared to 75 from individuals. Error rate was three orders of magnitude lower than the organization's norm. 

Nosek (1998) compared five experienced programmers working independently and ten others working in pairs. All teams outperformed the individuals, completing their tasks 40% faster and producing better code.  

A survey by Williams (1999) found that 96% enjoyed their job more when pair programming. 

Cockburn and Williams (2001) reported that pair programming incurs 15% extra development cost. But in the long term, it saves 15x the cost when bugs are discovered during testing or 60x the cost when bugs are experienced by customers. 

Hulkko and Abrahamsson (2005) empirically found that pair programming is most useful for learning and complex tasks. It leads to higher comment ratio. It doesn't always increase productivity, decrease defect count or conform to coding guidelines. 


### What are some concerns or criticisms of pair programming?

Not every developer is a fan of pair programming, particularly when it's imposed on them by the management. Developers like to be trusted and pair programming makes them feel they're being watched. However, once the benefits of pair programming are understood, developers are more likely to question the implementation rather than the practice itself. 

Some problems require deep thinking that's best done in isolation. One approach is to work out the solution in advance before starting a pair programming session. In fact, humans can't multitask effectively. Pair programming requires the pair to constantly communicate while also performing their individual tasks. 

There could be a personality clash. Developers are usually introverts. To them, pair programming can be overstimulating. Even for extroverts, pair programming all the time can be exhausting. Feedback between sessions is useful but developers are not naturally inclined to share feedback. 

Two developers doing the job of one is sometimes seen as wasteful. Pairing two novices maybe ineffective but other types of pairings if correctly implemented bring long term rewards. 

Lack of ownership and accountability can be a problem. The developer who creates the pull request can be made accountable. 

## Milestones

1945

ENIAC, the first programmable, electronic digital computer is completed. In an interview in 2011, one of ENIAC's programmers, Jean Jennings Bartik, claims that she and Betty Synder were a pair and they programmed together. This anecdote shows that pair programming is certainly not an invention of the 21st century.

1950

Fred Brooks, author of *The Mythical Man-Month (1975)*, has claimed that he and fellow graduate student Bill Wright programmed together in the 1950s. He claims, "We produced 1,500 lines of defect-free code; it ran correctly first try." 

1980

In the early 1980s, Larry Constantine visits P.J. Plaugher's software company, Whitesmiths, Ltd. He observes a room full of two programmers working at each computer. He calls them "dynamic duos". Their code was defect-free. He states that, "Two programmers in tandem is not redundancy; it's a direct route to greater efficiency and better quality." 

1998

Nosek publishes *The Case for Collaborative Programming*, which is perhaps the first empirical study on the subject using experienced programmers. An earlier 1993 study by Wilson et al. used student programmers. Also in 1998, **Extreme Programming (XP)** as practiced at Chrysler is talked about. Pair programming is one of the core practices within XP. 

2000

Some practitioners of XP introduce the **roles of driver and navigator** to explain pair programming in a better way. 

2002

The book *Pair Programming Illuminated* by Williams and Kessler is the first book dedicated to pair programming. It's also perhaps a sign that pair programming is ready for mainstream adoption.

2003

The **ping-pong style** of pairing is suggested on C2 Wiki. This combines pair programming with test-driven development. 

2012

On his blog, Arlo Belshee coins the term **strong-style** for the style of programming advocated by Llewellyn Falco. In July 2016, Falco and his colleague Maaret Pyhäjärvi present this style at the Agile2016 conference.