Pair Programming in Theory and Practice - Talk presented at XP Conference India 2015 by Garrick West

1. PAIR PROGRAMMING IN
THEORY & IN PRACTICE
GARRICK WEST
SOLUTIONSIQ
August 6th, 2015

2. PAIR PROGRAMMING IN THEORY & IN
PRACTICE
• Agenda
• Background
• Controversy in theory (a.k.a. The 7 myths about pair programming)
• Enlightenment in theory & in practice (a.k.a. The 7 synergies of pair programming)
• Pairing Practice Tips
• Games, Scripts, Dialogue, 4 C’s
• Mechanics
• Q&A
• Resources

3. BACKGROUND
• Q: What is Pair Programming?
• A: Pair programming is an agile software development technique in which
two programmers work together at one workstation. One, the driver,
writes code while the other, the […] navigator reviews each line of code as it is
typed in. The two programmers switch roles frequently. While reviewing, the
[navigator] also considers the "strategic" direction of the work, coming up with ideas
for improvements and likely future problems to address. This frees the driver to
focus all of his or her attention on the "tactical" aspects of completing the current
task, using the observer as a safety net and guide. *
Source: Wackypedia http://en.wikipedia.org/wiki/Pair_programming with minor edits
noted

4. MORE BACKGROUND
• Q: Where did Pair Programming come from?
• A: A few indications it emerged organically from different projects,
problem domains & environments. Largely popularized by eXtreme
Programming.
• Q: Why would you want to do it?
• A: A number of reasons we’ll get into shortly, but they all fall under the
same agile axiom: FAST FEEDBACK CYCLES!

5. EVEN MORE BACKGROUND!
CHECK OUT ‘THE WHITE
BOOK’ SOMETIME:
80%+ OF THIS
PRESENTATION IS FROM
THIS BOOK:

6. 7 MYTHS ABOUT PAIR PROGRAMMING

7. CONTROVERSY IN THEORY
• As called out in Pair Programming Illuminated, there are at least 7
myths that are popularized about Pair Programming.
• Some of these come from a management perspective and
misunderstanding of what Pair Programming is (or what programming
is at all!)
• Some of these come from an inexperienced programmer’s
perspective of what Pair Programming is.
• Play along and see if you can spot where each myth likely comes
from☺

8. MYTH 1: IT WILL DOUBLE THE WORKLOAD
WITH TWO DOING THE WORK ONE CAN
DO.
Solo Pair Delta
Time to complete 100 hours 57 hours -43%
Cost 100 hours 114 hours +14%
Defects 10 4 -60%
"Strengthening the Case for Pair Programming"
Williams, Kessler, Cunningham, Jeffries
IEEE Software, Volume 17, July 2000

9. MYTH 2: I'LL NEVER GET TO WORK ALONE.
I COULDN'T STAND THAT!
• Pair Programming done well is INTENSE! Many companies that do
Pair Programming set core pairing hours and determine what context
of work they want to support Pair Programming for.
• There’s always opportunities to do “spike work”, bug triage, research,
etc.
• A number of teams that favor pairing for production code adopt a “pair
or code review PRIOR to check-in”. That is to say, no production
code hits the repository without peer review.

10. MYTH 3: IT WILL WORK WELL ONLY WITH
THE RIGHT PARTNER.
• There’s a number of attributes that help make up “the right partner”,
and many people can embody that. The important thing for a pair to
be willing to work together. More about that later…
• A caveat is to recognize that when pairing with someone with limited
experience (domain, tools, whatever) you should be aware that you’re
effectively MENTORING and be willing to take on that role.

11. MYTH 4: PAIR PROGRAMMING IS GOOD FOR
TRAINING. BUT, ONCE YOU KNOW WHAT
YOU'RE DOING, IT IS A WASTE OF TIME.
• Nobody is an expert in EVERYTHING. There’s also a host of synergies we’ll be
seeing shortly.
• If you pair two experts when you've got a really complex problem to solve, they will
do the best job imaginable. Because each is probably an expert in a slightly or very
different area, the synergy of their expertise will bring results.
• If you pair any two experienced programmers, they will fill in many of each other's
knowledge gaps. Between the two of them, they can piece together the solution to
almost any problem, including problems they would have struggled with alone. This
is also a great knowledge management strategy & an excellent way to pass tacit
knowledge around a team.
• There’s about 10 more examples as well (See Pair Programming Illuminated).

12. MYTH 5: I'LL NEVER GET CREDIT FOR DOING
ANYTHING. I'LL HAVE TO SHARE ALL THE
RECOGNITION WITH MY PARTNER.
• It’s good to have one person “own” a story, rotating knowledge
through the team by recruiting people to pair with them on it. They’re
then a point of continuity for it while sharing knowledge with the whole
team: a natural candidate for the demo at the end of a Sprint.
• Software development at scale is a team sport. There’s always ways
(like the “story owner” concept) to shine as an individual while reveling
in the success of the team as a whole.

13. MYTH 6: THE NAVIGATOR FINDS ONLY SYNTAX
MISTAKES. HOW BORING IS THAT! COMPILERS
CAN DO THAT BETTER THAN HUMANS CAN
ANYWAY.
• The driver/navigator relationship is a lot more like a rally car situation:
the navigator is looking a fine points of syntax & structure while also
thinking more about naming consistency, object responsibility,
possible code re-use, upcoming edge cases, missing tests, and so on
& so on…
• Mistakes & corrections are respectively caught & made sooner,
making over all progress greater than it would be solo.

14. MYTH 7: THE ONLY TIME I EVER GET ANY REAL
WORK DONE IS WHEN I'M ALONE. NOW, I'LL
NEVER GET ANYTHING DONE! PAIR
PROGRAMMING WOULD DRIVE ME CRAZY.
• Part of getting things done is trying to get into mental “flow” and avoiding a state of
mental “block”
• When pairs work together, they do a much better job at deferring interruptions. They
forward their phone to voicemail, they turn off their e-mail notification, and they don't
take "surf the Web" breaks. When other people walk by and see them working, they
often choose not to interrupt.
• Pair programming reduces this obstruction either because the pairs keep each other
on track (and are not distracted) or because one of the pair is able to break through
the mental block. Often, either one of the pair can at least start any task, no matter
how impossible it seems initially.

15. THE 7 SYNERGIES OF PAIR
PROGRAMMING

16. ENLIGHTENMENT IN THEORY & PRACTICE
• Also called out in Pair Programming Illuminated, there are at least 7
synergistic behaviors people experience while Pair Programming.
• Many of these are simply aspects of good collaboration and might apply
to any paired activity.
• Some of them feel as though they increase productivity and effectiveness
of common programming tasks exponentially!
• Look for these sentiments to resonate with your pair programming
experiences☺

17. SYNERGY 1: PAIR PRESSURE
• Pair Pressure - Positive encouragement: not wanting to let partner
down + satisfaction of working harder & smarter than alone.
• Shared focus on the task at hand. Less likelihood to get side-tracked or
distracted
• It’s easier to get engaged and started on tasks
• It’s easier to push through difficult tasks
• It’s easier to decide you’ve completed and can wrap up tasks

18. SYNERGY 2: PAIR NEGOTIATION
• Pair Negotiation - combining two sets of skills for design &
implementation yielding the best solution that fits.
• The pair discusses different approaches and combines the best elements to
solve the problem.
• Brainstorming can be greatly enhanced as the pair bounce ideas off of each
other and look to optimize and improve.
• The negotiating process helps sharpen focus on the problem at hand.

19. SYNERGY 3: PAIR COURAGE
• Pair Courage - advantage of not being alone in a challenging task,
trying together what one may not alone.
• Also helps get your going and avoid analysis paralysis
• If your courage falters, your pair can help you push through
• Helps reinforce the team will follow through with tough agreements – like TDD
for code, commitment to unit test coverage, etc.

20. SYNERGY 4: PAIR REVIEW
• Pair Review - the continuous review of design & implementation that
happens in context and is more likely to be acted upon.
• If a design starts to go wrong, it’s more likely to be recognized sooner, and less
likely to be followed through.
• The pair working together shares the same context. Ever been in a code review
that required spending all your time explaining (defending?) what was done and
why to have it ultimately moved past with no real improvements or changes?

21. SYNERGY 5: PAIR
DEBUGGING
• Pair Debugging - going from problem identification to
fix in a more enjoyable and often far shorter path than
by an individual.
• This may be familiar if you ever simply go to
someone and describe a problem, only to solve it
yourself as the words come out of your mouth.
• On particularly difficult bugs “pair debugging” has
probably happened going back to the beginning of
computing (at least September 9th, 1947 with the
Harvard Mark II).

22. SYNERGY 6: PAIR LEARNING
• Pair Learning - acquiring and/or improving skills while delivering value
through working with another.
• Nobody is an expert in EVERYTHING!
• Even if you know a large percentage of some topic, consider that you don’t
know it all AND if it’s some aspect of technology it is in the process of changing
constantly.
• Someone else’s point of view can also happily make you rethink how you
understand and relate something you’re already extremely competent at (thus
making you more so).

23. SYNERGY 7: PAIR TRUST
• Pair Trust - each individual becomes more confident in their skills and
communication to present their best ideas as they feel supported.
• This is a strong type of team building.
• Over time, individual programmers feel more confident in how they can help the
team succeed.

24. PAIRING PRACTICE TIPS – SESSIONS &
GAMES
• Set up your pairing session:
• For how long? Or to accomplish what? When should we switch pairs?
• Focus & tell people who interrupt BOTH of you to go away
• Use a pairing game when you’re new to the practice
• Ping Pong
• Beat the clock

25. PAIRING PRACTICE TIPS – DIALOGUE &
4C’S
• Always use constructive dialogue tools when pairing:
• Roman vote, time-box discussions if needed
• Propose ideas, confirm agreement, get ‘buy in’ for your group of two
• Check your 4 C’s as you make progress:
• Communication
• Comfort
• Confidence
• Compromise

26. PAIRING PRACTICE TIPS - MECHANICS
• Better hardware!: 1screen/1input < 1screen/2inputs < 2screens/2inputs
• Turn on line numbers in an IDE or text editor. It’s far easier for the
navigator and driver both to reference them in discussion.
• ASK for mouse/keyboard control, don’t fight!
• Point with your mouse, not your finger when using mirrored monitors.
• Remote pairing with desktop sharing & voice is limited. A significant
portion of human communication is nonverbal, so add video chat if
possible.

27. QUESTIONS?
• Resources:
• Pair Programming Illuminated, Williams & Kessler
http://www.amazon.com/Pair-Programming-Illuminated-Laurie-
Williams/dp/0201745763
• All I Really Need to Know about Pair Programming I Learned In Kindergarten
http://www2.yk.psu.edu/~sg3/cmpbd205/assign/week01/ACMarticlePairProgram
ming.pdf
• Pair Programming Cheat Sheet
https://coderwall.com/p/mbj7ta

28. SAMPLE PAIRING HOURS
• 10:00 am – 12:00 pm
• 1:00 pm – 2:30pm
• 3:00 pm – 4:30 pm