Pair Programming Talk

659 views

Published on

Pair programming presentation given to Phoenix Agile User's Group in 2002

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
659
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
40
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Pair Programming Talk

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

×