Skip to main content
Pair Programming Langr Software Solutions Originally presented to the Phoenix XP Users Group, October 2002
The Rules All production software Two programmers jointly developing code Switch pairs frequently Must pair if asked
Dynamics Two roles in the pair: Strategic Tactical Developers switch roles frequently Rhythm
Mechanics Comfortable workstations that accommodate two Side by side Switch pairs at least once a day Core pairing hours Take breaks!
General Benefits Continual review Coverage Minimized personnel dependencies Improved design Minimized defects Sustainable More rapid solutions
More Benefits Improved communication Consistent pacing Individuals less likely to bog down Team members rise to common level Builds a true
Management Benefits Reduced risk Rapid training for new hires Interviewing criteria Problems less hidden Peer pressure Resource fluidity Cross-pollination
Developer Benefits Awareness of other parts of system Resume building Decreased time in meetings Continuous education Ability to move between teams Rapid learning as new hire The little things E.g. Eclipse shortcuts
“But it takes twice as long…” What about… Debugging sessions? Increased cost of change due to poorer design? Mull time? Inconsistent team abilities “ Costs and Benefits of Pair Programming” Laurie Williams, Alistair Cockburn
Potential Issues Pair dynamics Extrovert and Introvert mixes Expert and Novice mixes Not everyone can work this way Most enjoy it Some dislike but appreciate its benefits A small percentage will refuse Fear
Other Considerations Odd number of team members Core hours Skiing Team of one or two Distributed developers Context switching
When Not Pairing Meetings, email, documents, etc. Review existing code Determine areas for potential refactoring Spike solutions Build tools or AT framework If you must work on production code: Come up with ground rules Do post-development inspections
Where Do I Start? Discuss it with your development team Determine its value Learn to pair first  To learn when not to pair Influence through metrics If necessary, track pairing vs. not Re-assess pairing value regularly Ensure a coach is monitoring interaction issues