Pair Programming Langr Software Solutions Originally presented to the Phoenix XP Users Group, October 2002 Last updated 2010
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Pairing Two programmers Jointly developing production software Not I watch over your shoulder (That sounds like it would be waste of time!)
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Dynamics Must pair if asked Two roles in the pair: Strategic Tactical Developers switch roles frequently Rhythm
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Mechanics Comfortable workstations Accommodate two side by side Separate or shared input devices Switch pairs at least once a day 3x / day? Core pairing hours Take breaks!
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Technique Variants Ping-pong pairing I code test, you code solution; we switch Promiscuous pairing Least-skilled remains on task Promiscuous keyboarding Keyboarder switches every minute Face-to-face
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Additional Guidelines 5-minute argument rule 5-second typo rule Be attentive!
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Review Goals: Remove defects Prevent similar mistakes in future Generate useful data Pairing != formal review process Different costs, focus, outcomes
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Formal Review Challenges Disinterested parties That weren't involved in creating solution View product of others as a distraction Find mostly low-hanging fruit Anything occurring after the fact... Often doesn't get done or done well Often doesn't result in changes Pairing invests the reviewer
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Context Switching Incurs overhead cost Should drive toward cleaner solution Focus on unit test cases as doc Task owner describes current test case New partner helps flesh out test Can quickly understand how to realize shouldDoSomethingWhenThisCondition
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. General Benefits Continual review Coverage Minimized personnel dependencies Improved design Minimized defects Sustainable More rapid solutions
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Additional Benefits Improved understanding Minimizes open workspace distractions Consistent pacing Individuals less likely to bog down Team members rise to common level Increased collaboration Helps build a true team
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Management Benefits Reduced risk (better truck number!) Rapid training for new hires Interviewing criteria Problems less hidden Peer pressure Resource fluidity Cross-pollination
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Developer Benefits Awareness of other parts of system Resume building Decreased time in (review) meetings Continuous education Ability to move between teams Rapid learning as new hire The little things e.g. Eclipse shortcuts
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. But it takes twice as long… Consider: Debugging sessions Increased cost of change due to poorer design Mull time Inconsistent team abilities Learning time
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Studies Costs and Benefits of Pair Programming Laurie Williams, Alistair Cockburn Pair: 15% slower Error free code went from 70% to 85% "The Effect of Pairs in Program Design Tasks" Lui, KM, et al, IEEE Transactions, 2008 "Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise" Arisholm, E. +84% effort to perform tasks correctly More complex systems: +48% correct solutions
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Issues Pair dynamics Extrovert and Introvert mixes Expert and Novice mixes Not everyone can work this way If done well, many like it Some dislike but appreciate its benefits A small percentage will refuse Social preferences / culture Fear Personal habits
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. I Like My Space You can still have it But... building software is a team activity Find a balance between pairing and not Never mandate all or nothing
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Other Considerations Odd # of team members Core hours Team of Distributed developers Context switching overhead
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. When Not Pairing Meetings, , documents, etc. Review existing code Analyze to understand of design/defect 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
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Where Do I Start? Discuss it with your team Agree on the values you want to derive Create an initial simple set of rules Revisit regularly Learn to pair first To learn when not to pair Influence through metrics If necessary, track pairing vs. not Re-assess value regularly Ensure a coach monitors interaction issues
Copyright © 2010 by Langr Software Solutions. All Rights Reserved. Further Reading Atwood, Jeff. Langr, Jeff. Agile Alliance articles in category Pair Programming