Your SlideShare is downloading. ×
Introducing Pair Programming                  Steve Smith                  Senior Architect                  The Code Proj...
Our SponsorsPlatinumGoldSilverOther
http://www.flickr.com/photos/menlopics/3928250043/
It’s We not MePairing is part of a larger process…Becoming a software development TEAM.
Pair Programming      Who      What     Where     When      Why      How
Who Pairs?             http://www.flickr.com/photos/isafmedia/4990043858/             http://www.flickr.com/photos/thenati...
Who Should Pair?
http://www.flickr.com/photos/svet/4641090741
http://www.flickr.com/photos/elefevre/4373756868/
Who Shouldn’t?
• “One of the reasons I wanted to be a programmer, is so  I don’t have to deal with people all the time!”   – If you don’t...
• “The other guy thinks too slowly; I don’t want  to be a teacher all day long!”  – If you teach well, they will speed up ...
What is Pair Programming?
Pair ProgrammingTwo programmers develop software side by side  at one computer.• Also known as collaborative programming• ...
Pair Programming• Pair programming is a social skill that takes  time to learn.• Pair programming is not mentoring, but tw...
http://www.extremeprogramming.org/map/code.html
Where is Pair Programming done?
Where• Best with co-located teams• Best with sufficient space for two people to  work comfortably at one computer• Try to ...
http://www.flickr.com/photos/halfaloafoftofu/413474322/
More Bad Layouts
Better Layouts
Ideal Layouts - Tables
Team Rooms
Pair Workstations
When should you pair?
When should you pair?•   Complex code•   Mission-critical code•   Code that involves design decisions•   Areas of code tha...
You do this already• When you ask for help with a tricky bug• When you run a new design by a teammate• When you have someo...
When shouldn’t you pair?•   Mundane tasks•   Fixing simple typos•   Spikes•   When distracted    – Checking email, twitter...
Todd asks:“During an ‘average’ day, what would be an  appropriate amount of time to pair program?  Entire day? Several hou...
When should you switch roles?
Ping Pong Pairing
Ping Pong Pairing• Alice (Pilot) writes a failing test[Roles Switch]• Bob (new Pilot) writes the smallest amount of  code ...
Ping Pong PairingDEMO
Pomodoro Technique• Do Focused Work for 25 minutes• Use a timer• Take a 5-minute break• Take a longer break after several ...
Why?
Benefits• Better code• Knowledge transfer / sharing• More fun – better morale• Higher productivity – fewer distractions an...
More Benefits• Continual review• Improved design• Fewer defects• Minimized personnel dependencies and info  silos• Builds ...
Do the math• It doesn’t take twice as long  – Studies show 15% overhead imposed• It produces fewer defects and better desi...
How?
How does it work?•   Collaborate•   Respect one another•   Set up your workspace so you can be effective•   Alternate role...
Be a good Driver•   Focus on the task•   Do the simplest thing that can possibly work•   Talk through your thought process...
Be a good Navigator• Stay involved – pay attention• Review the code• Make notes about things that you’ll need to  come bac...
How do you decide what to work on?Some options:• Pairs grab the next story from the queue together.• Alternate which pair ...
How does it work with more than 2?
How do you do it remotely?
Tools for Remote PairingVoice and Screen   Files• Skype            • Source Control• GoToMeeting      • Dropbox• LiveMeeti...
How do you convince management?
It reduces productivity!• When people say that Pair Programming  reduces productivity, I answer "that would be  true if th...
Take the long view                        Experienced                        with Pairing:Just Learning to Pair   15% over...
Take the long view                 From 70% to 85%. 15%                 raw change; 21% better.
Take the long view
Take the long view• 15% increase in code development time• 15% reduction in defectsExample:    A 50,000 LOC application mi...
How: Source ControlWho checks out the code if you’re in pairs?• Practice Collective Code Ownership  – User per Workstation...
Parting Thoughts
Introducing… the PairOn
You’re Doing It Wrong                        http://www.flickr.com/photos/shadowstorm/3985346700
References•   http://en.wikipedia.org/wiki/Pair_programming•   http://www.slideshare.net/Siddhi/intro-to-pair-programming•...
Pair Programming - Summary•   Catch more mistakes as they are typed•   Improve software design•   Solve problems faster•  ...
Discuss          Find me online:          SteveSmithBlog.com          Twitter: @ardalis
Introducing Pair Programming
Introducing Pair Programming
Introducing Pair Programming
Introducing Pair Programming
Introducing Pair Programming
Introducing Pair Programming
Upcoming SlideShare
Loading in...5
×

Introducing Pair Programming

2,999

Published on

An introduction to pair programming given at the Cincinnati Day of Agile 2011.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,999
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Introducing Pair Programming"

  1. 1. Introducing Pair Programming Steve Smith Senior Architect The Code Project http://SteveSmithBlog.com Twitter: @ardalis
  2. 2. Our SponsorsPlatinumGoldSilverOther
  3. 3. http://www.flickr.com/photos/menlopics/3928250043/
  4. 4. It’s We not MePairing is part of a larger process…Becoming a software development TEAM.
  5. 5. Pair Programming Who What Where When Why How
  6. 6. Who Pairs? http://www.flickr.com/photos/isafmedia/4990043858/ http://www.flickr.com/photos/thenationalguard/4535036556/ http://www.flickr.com/photos/flyforfun/3264854289/ http://www.flickr.com/photos/bestinplastics/4893299962/ http://www.flickr.com/photos/wonderlane/315466291/
  7. 7. Who Should Pair?
  8. 8. http://www.flickr.com/photos/svet/4641090741
  9. 9. http://www.flickr.com/photos/elefevre/4373756868/
  10. 10. Who Shouldn’t?
  11. 11. • “One of the reasons I wanted to be a programmer, is so I don’t have to deal with people all the time!” – If you don’t like dealing with people, you have worse problems than Pair Programming• “The other guy smells!” – Get him to get a job at a non-agile shop.• “Why should I play secretary and type in the code as it is dictated to me?” – You shouldn’t, that’s not Pair Programming. If your partner is failing to think strategically and is instead dictating code to you, hand them the keyboard. http://c2.com/cgi/wiki?PairProgrammingDoubts
  12. 12. • “The other guy thinks too slowly; I don’t want to be a teacher all day long!” – If you teach well, they will speed up over time – Change pairs; all day is too long to pair with one person.• “The other person types so slowly, I get impatient!” – Patience is a virtue; learn it. – Typing competently is a virtue; learn it. http://c2.com/cgi/wiki?PairProgrammingDoubts
  13. 13. What is Pair Programming?
  14. 14. Pair ProgrammingTwo programmers develop software side by side at one computer.• Also known as collaborative programming• Each person in the pair generally plays the role of either Driver or Navigator at any given time• Roles shift back and forth frequently
  15. 15. Pair Programming• Pair programming is a social skill that takes time to learn.• Pair programming is not mentoring, but two people working together as equals – Of course, working together at one computer is also an excellent mentoring practice
  16. 16. http://www.extremeprogramming.org/map/code.html
  17. 17. Where is Pair Programming done?
  18. 18. Where• Best with co-located teams• Best with sufficient space for two people to work comfortably at one computer• Try to create a team room. Tear down cubicle walls. Eliminate L- and U-shaped desks.
  19. 19. http://www.flickr.com/photos/halfaloafoftofu/413474322/
  20. 20. More Bad Layouts
  21. 21. Better Layouts
  22. 22. Ideal Layouts - Tables
  23. 23. Team Rooms
  24. 24. Pair Workstations
  25. 25. When should you pair?
  26. 26. When should you pair?• Complex code• Mission-critical code• Code that involves design decisions• Areas of code that you want everyone on the team to know how to work with – Keep your truck number high
  27. 27. You do this already• When you ask for help with a tricky bug• When you run a new design by a teammate• When you have someone look over that scary database update you’re about to run• You know it works.
  28. 28. When shouldn’t you pair?• Mundane tasks• Fixing simple typos• Spikes• When distracted – Checking email, twitter, facebook, etc• You’re sick! – Stay home! Or at least in your own workspace!
  29. 29. Todd asks:“During an ‘average’ day, what would be an appropriate amount of time to pair program? Entire day? Several hours at a time? Are there diminishing returns if two people spend too much time together during the day?”When should you switch pairing partners?
  30. 30. When should you switch roles?
  31. 31. Ping Pong Pairing
  32. 32. Ping Pong Pairing• Alice (Pilot) writes a failing test[Roles Switch]• Bob (new Pilot) writes the smallest amount of code possible to make the test pass.• Bob refactors if needed (with Alice’s input)• Bob writes a failing test for the next bit of functionality[Roles Switch]
  33. 33. Ping Pong PairingDEMO
  34. 34. Pomodoro Technique• Do Focused Work for 25 minutes• Use a timer• Take a 5-minute break• Take a longer break after several work periods• Switch Pilot/Navigator every 25 minutes• Switch partners regularly, too (2-4 times/day)
  35. 35. Why?
  36. 36. Benefits• Better code• Knowledge transfer / sharing• More fun – better morale• Higher productivity – fewer distractions and blocks• Improved communication and team cooperation
  37. 37. More Benefits• Continual review• Improved design• Fewer defects• Minimized personnel dependencies and info silos• Builds a true TEAM• Rapidly integrates new hires
  38. 38. Do the math• It doesn’t take twice as long – Studies show 15% overhead imposed• It produces fewer defects and better designs – Fewer bugs when shipped (15%) – More flexible system when it needs to change• Improves team morale and employee satisfaction – Less turnover – Larger truck factor
  39. 39. How?
  40. 40. How does it work?• Collaborate• Respect one another• Set up your workspace so you can be effective• Alternate roles frequently• Stay engaged and communicate frequently – Think out loud• Wait 10 seconds before pointing out any typo – Be patient with your partner
  41. 41. Be a good Driver• Focus on the task• Do the simplest thing that can possibly work• Talk through your thought process as you go• Refactor if you and Navigator agree it’s time – Only when tests are green – Don’t forget to refactor the tests!
  42. 42. Be a good Navigator• Stay involved – pay attention• Review the code• Make notes about things that you’ll need to come back to later – Let Driver focus on task at hand• Consider the big picture, not the syntax – Consider alternatives; is this the right approach?• Keep Driver disciplined and writing Clean Code!
  43. 43. How do you decide what to work on?Some options:• Pairs grab the next story from the queue together.• Alternate which pair member chooses the story to be worked on• Whoever asks someone to pair with them has already determined the task to work on• Assign stories to pairing stations, not to individuals.
  44. 44. How does it work with more than 2?
  45. 45. How do you do it remotely?
  46. 46. Tools for Remote PairingVoice and Screen Files• Skype • Source Control• GoToMeeting • Dropbox• LiveMeeting • Live Sync / Live MeshScreen Only• Mikogo• Crossloop• VNC
  47. 47. How do you convince management?
  48. 48. It reduces productivity!• When people say that Pair Programming reduces productivity, I answer "that would be true if the most time consuming part of programming was typing" -- MartinFowler
  49. 49. Take the long view Experienced with Pairing:Just Learning to Pair 15% overhead
  50. 50. Take the long view From 70% to 85%. 15% raw change; 21% better.
  51. 51. Take the long view
  52. 52. Take the long view• 15% increase in code development time• 15% reduction in defectsExample: A 50,000 LOC application might take 1000 hours to develop. Pairs might take 15% longer: 1150 hours. Assume a bug rate of 100 per 1000 lines of code, but a thorough process removes 70% of these. That leaves 1500 bugs in the individuals’ code. Collaborators with 15% less would have 1275, or 225 fewer bugs. If each bug were to take just an hour to fix (which is low) you still come out ahead.
  53. 53. How: Source ControlWho checks out the code if you’re in pairs?• Practice Collective Code Ownership – User per Workstation – User per Pair – Switch Users Per Checkin and Per Role Change• Worst case: Note collaborator in comments
  54. 54. Parting Thoughts
  55. 55. Introducing… the PairOn
  56. 56. You’re Doing It Wrong http://www.flickr.com/photos/shadowstorm/3985346700
  57. 57. References• http://en.wikipedia.org/wiki/Pair_programming• http://www.slideshare.net/Siddhi/intro-to-pair-programming• http://www.slideshare.net/jlangr/pair-programming-talk-presentation• http://www.slideshare.net/rogercafe/pair-programming-presentation• http://www.slideshare.net/rachellaycock/pair-programming-good-bad-and-ugly• http://www.slideshare.net/dennisdoomen/the-10-habits-of-highly-effective-programmers• http://www.codinghorror.com/blog/2007/11/pair-programming-vs-code-reviews.html• http://en.wikipedia.org/wiki/Pomodoro_Technique• http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
  58. 58. Pair Programming - Summary• Catch more mistakes as they are typed• Improve software design• Solve problems faster• Learn and transfer knowledge better• Create an real team• People enjoy their work more
  59. 59. Discuss Find me online: SteveSmithBlog.com Twitter: @ardalis

×