According to the Agile organization, pairing programming is a collaborative exercise in which two developers share one workstation. The person at the keyboard is usually called the “driver”, while the other is the “navigator” being her focus on the overall direction. It is expected that they swap roles every few minutes or so.
The goal is that both people talk through each idea and action and learn from each other’s knowledge and skill set. In fact, it is a common practice in my current company that originates quite naturally within my team when there is a complex task at hand. These are some of the benefits that I have personally observed.
- Better code quality: peer revision is fundamental to produce valuable deliverables.
- Better diffusion of knowledge across the team fostering cross-functionality.
- Mentoring when a developer unfamiliar with a component pairs with an expert.
- Reduction in coordination efforts for the team facilitator.
Clearly, one of the main pitfalls is resource overhead (around 15% according to the studies cited in the article). In addition, we should also pay attention to avoid the following behaviors to secure an effective pair programming.
- Passivity kills collaboration; both programmers must be actively engaged.
- Pair programming is also programming out loud, i.e. the driver cannot be silent.
- This cannot be fruitfully forced upon people, especially if relationship issues exist.
How is it in your company? Do you practice pairing often?
Let me know in the comments!
PM Reflections 