Your SlideShare is downloading. ×
Pair Programming Talk
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Pair Programming Talk

513
views

Published on

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

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
513
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Pair Programming Langr Software Solutions Originally presented to the Phoenix XP Users Group, October 2002
  • 2. The Rules
    • All production software
    • Two programmers jointly developing code
    • Switch pairs frequently
    • Must pair if asked
  • 3. Dynamics
    • Two roles in the pair:
      • Strategic
      • Tactical
    • Developers switch roles frequently
    • Rhythm
  • 4. Mechanics
    • Comfortable workstations that accommodate two
      • Side by side
    • Switch pairs at least once a day
    • Core pairing hours
    • Take breaks!
  • 5. General Benefits
    • Continual review
    • Coverage
    • Minimized personnel dependencies
    • Improved design
    • Minimized defects
    • Sustainable
    • More rapid solutions
  • 6. More Benefits
    • Improved communication
    • Consistent pacing
      • Individuals less likely to bog down
    • Team members rise to common level
    • Builds a true
  • 7. Management Benefits
    • Reduced risk
    • Rapid training for new hires
    • Interviewing criteria
    • Problems less hidden
    • Peer pressure
    • Resource fluidity
    • Cross-pollination
  • 8. 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
  • 9. “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
  • 10. 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
  • 11. Other Considerations
    • Odd number of team members
    • Core hours
      • Skiing
    • Team of one or two
    • Distributed developers
    • Context switching
  • 12. 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
  • 13. 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