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

1. Introducing Pair Programming
Steve Smith
Senior Architect
The Code Project
http://SteveSmithBlog.com
Twitter: @ardalis

2. Our Sponsors
Platinum
Gold
Silver
Other

3. http://www.flickr.com/photos/menlopics/3928250043/

4. It’s We not Me
Pairing is part of a larger process…
Becoming a software development TEAM.

5. Pair Programming
Who
What
Where
When
Why
How

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. Who Should Pair?

8. http://www.flickr.com/photos/svet/4641090741

9. http://www.flickr.com/photos/elefevre/4373756868/

10. Who Shouldn’t?

12. • “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

13. • “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

14. What is Pair Programming?

15. Pair Programming
Two 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

16. 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

17. http://www.extremeprogramming.org/map/code.html

18. Where is Pair Programming done?

19. 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.

22. http://www.flickr.com/photos/halfaloafoftofu/413474322/

23. More Bad Layouts

24. Better Layouts

25. Ideal Layouts - Tables

26. Team Rooms

27. Pair Workstations

29. When should you pair?

30. 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

31. 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.

32. 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!

33. 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?

34. When should you switch roles?

35. Ping Pong Pairing

36. 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]

37. Ping Pong Pairing
DEMO

38. 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)

39. Why?

40. Benefits
• Better code
• Knowledge transfer / sharing
• More fun – better morale
• Higher productivity – fewer distractions and
blocks
• Improved communication and team
cooperation

41. More Benefits
• Continual review
• Improved design
• Fewer defects
• Minimized personnel dependencies and info
silos
• Builds a true TEAM
• Rapidly integrates new hires

42. 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

43. How?

44. 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

45. 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!

46. 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!

47. 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.

48. How does it work with more than 2?

49. How do you do it remotely?

50. Tools for Remote Pairing
Voice and Screen Files
• Skype • Source Control
• GoToMeeting • Dropbox
• LiveMeeting
• Live Sync / Live Mesh
Screen Only
• Mikogo
• Crossloop
• VNC

51. How do you convince management?

52. 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

53. Take the long view
Experienced
with Pairing:
Just Learning to Pair 15% overhead

54. Take the long view
From 70% to 85%. 15%
raw change; 21% better.

55. Take the long view

57. Take the long view
• 15% increase in code development time
• 15% reduction in defects
Example:
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.

58. How: Source Control
Who 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

59. Parting Thoughts

60. Introducing… the PairOn

62. You’re Doing It Wrong
http://www.flickr.com/photos/shadowstorm/3985346700

63. 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

64. 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

65. Discuss
Find me online:
SteveSmithBlog.com
Twitter: @ardalis