The Pros & Cons Of Pair Programming (With Examples)
This YouTube video by Dave Farley discusses the pros and cons of pair programming, based on his 20 years of experience. Key points include:
Initial Resistance & Subsequent Love: Many programmers initially dislike the idea of pair programming, but a significant majority who try it for a substantial period come to appreciate it. This is attributed to misconceptions about its practicality.
Myths & Excuses vs. Real Concerns: The video differentiates between common excuses for avoiding pair programming (it’s too slow, disruptive, inefficient, etc.) and genuine concerns. Farley argues that the productivity concerns stem from a narrow view of developer productivity. Good programming prioritizes clear thinking and simple code over fast typing. The subtle, long-term benefits (better code quality, reduced debugging, etc.) often outweigh the perceived initial slowdowns.
Real Pros of Pair Programming:
- Improved Code Quality: Pair programming leads to cleaner, more maintainable, and better-understood code.
- Faster Problem Solving: Two minds working together often solve problems more efficiently.
- Knowledge Sharing & Team Building: Regular pair rotation fosters collaboration, knowledge sharing, and stronger team relationships. This boosts team learning and individual growth.
- Reduced Bugs & Production Issues: The collaborative nature results in fewer bugs, requiring less time on debugging and fixing production issues later.
- Psychological Safety: Pair programming contributes significantly to psychological safety within a team, a major factor in high-performing teams (as per Google’s Project Aristotle).
Real Cons of Pair Programming (and how to address them):
- The seemingly higher initial cost: While it seems inefficient to pay two people for one job, the long-term gains in quality and reduced debugging time compensate.
- Disruption of flow: This is a valid concern but less significant than many believe, and the benefits outweigh this cost.
Example of Pair Programming: The video shows a pair programming session refactoring poorly written Java code. It highlights the collaborative discussion, problem-solving, and incremental improvements made through discussion and code review before significant changes are implemented. This demonstrates the process of strategizing, identifying problems, and collaboratively finding solutions. The use of approval testing is emphasized to ensure the refactoring doesn’t break existing functionality.
Conclusion: Farley strongly advocates for pair programming, especially in teams organized around this practice, as the most effective tool he knows for building high-quality software. The long-term benefits, particularly the cultural impact and improved team dynamics, far outweigh any perceived initial drawbacks.