PAIR PROGRAMMING IN THEORY & IN PRACTICEGARRICK WEST

SOLUTIONSIQ

August 6th, 2015

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

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

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!

EVEN MORE BACKGROUND!

CHECK OUT ‘THE WHITE BOOK’ SOMETIME:

80%+ OF THIS PRESENTATION IS FROM THIS BOOK:

7 MYTHS ABOUT PAIR PROGRAMMING

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☺

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

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.

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.

MYTH 4: PAIR PROGRAMMING IS GOOD FOR TRAINING. BUT, ONCE YOU KNOW WHATYOU'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).

MYTH 5: I'LL NEVER GET CREDIT FOR DOING ANYTHING. I'LL HAVE TO SHARE ALL THERECOGNITION 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.

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.

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.

THE 7 SYNERGIES OF PAIR PROGRAMMING

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☺

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

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.

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.

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?

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

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

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.

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

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

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.

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

SAMPLE PAIRING HOURS

• 10:00 am – 12:00 pm

• 1:00 pm – 2:30pm

• 3:00 pm – 4:30 pm