What is Pair Programming
Pair Programming (PP), is like TDD (Test-Driven Development) a best practice of eXtreme Programming (XP) that is also popular outside of XP. With Pair Programming, two developers work together on the same algorithm, design or piece of code, side by side in the same workplace.
Using collaborative real time editors, programmers can also be located in physical different locations. This is known as Virtual pair programming or distributed pair programming.
There is a clear division of roles. The first developer -the driver- is the one who operates the keyboard and actually writes the code. The second developer - the observer or navigator - checks (evaluates!) and thinks ahead. While the code is being written, the navigator is thinking about subsequent steps while the driver can fully focus on the technical aspects of the code at hand. Defects are quickly observed and removed.
The two developers regularly swap roles. This depends on the experience of the developers. They swap when they are at the same level of experience, otherwise the less experienced developer remains in the driver seat to learn and become a better developer.
In recent decades, this method has been cited at various times as a better way of developing software. Research has demonstrated that by deploying a second developer in Pair Programming, the costs do not rise by 100%, as may be expected, but only by around 15% [Cockburn, 2000]. The investment is recouped in the later phases as a result of the shorter and cheaper testing, QA and management.
A variant of pair programming is mob programming [Pyhäjärvi 2019]. This is when the whole team works together, for example on a hard problem or to learn from each other.
Why Pair Programming
The significant advantages of Pair Programming are:
- Many faults are caught during the typing, rather than during the tests or in use
- The number of defects in the end product is lower
- The (technical) designs are better and the number of code lines is lower
- The team solves problems faster
- The team members learn considerably more about the system and about software development
- The project ends with more team members understanding all parts of the system
- The team members learn to collaborate and speak to each other more often, resulting in improved information flows and team dynamic
- The team members enjoy their work more.