Pairing Techniques

driver-navigator Andy Parker:

• Navigator has to have a notebook.
• Looks out for bigger picture, what's the list of done criteria - list gets bigger and bigger
• Driver is thinking about next thing to type
• Need to agree when you're switching
• Can be good when skills unequal

ping pong

• uses the TDD cycle
• A writes a failing test, B makes it pass, then B writes another red test, then hands over to A who makes it pass

Jeffrey F: good when equal skills

AP: Doesn't work so well when teaching - learner tends to flounder

Ball and board One get keyboard, one gets mouse. keyboard user not allowed to move using arrows. Only hit Enter when both agree.

Antony Marcano: Isn't this a slow method?

PJ: Jeff Bey pairs with PJ and finds it's super-quick. Two senior people communicate through code or screen - this method helps them do this. Highlight something, type Ctrl-C. Move mouse somewhere else, type Ctrl-V. Good for less-verbal people (Asperger's). Do less pointing and talking.

Jeffrey F: works well if mouse person knows code, keyboard user is learning. Similar to Han Solo (keyboard person who is doing hero work) and Chewie (just navigates and grunts)

Batting practise Like ping pong, but I write test, you write code, I write another test, you write more passing code

Q: What about remote pairing? Antony M: TeamViewer works well. On Mac, iChat successful (but used Skype for voice, and video didn't work). Connection speed matters a lot.

Jeffrey F: SubEthaEdit is a collaborative editor

AM: best with voice, video, and screensharing. put voice and video on 2nd screen on one side so you look "toward" the other person

Q: How do you get control of keyboard? A: Work same as when you have two keyboards and mice in person

PJ: Used corporate phone connection, shared screen from one bank location to another

JF: Much harder if you're learning to pair and doing it the first time remotely - feels terrible and unproductive (even more so than when learning it in person!)

Rachel Davies: Another problem is how to "overhear" other pairs - has tried using a common Skype or IRC channel

JF: Virtual conference rooms - could try putting all the pairs in one such room (each pairing and screensharing)

Mike H: Virtual worlds! Log in together to something like Second Life and have a virtual office

RD: State Farm trying various virtual world methods to do this - very expensive. Jane Chandler talked about this topic a couple of years ago at a conference. Could use games in virtual worlds to socialise.

Spike M: Used to work at Second Life. Gives a feeling of space. Was initially sceptical, but has tried pairing in-world and found it valuable.

MH: Can script things for your team - build monitor, flash world red when tests fail or it's time for lunch.

SM: Add a timer for group meetings.

Pairing sceptics, where it's failed

Benjamin M: When you are trying to learn tennis, you ask how someone does a great serve and as the person tries to show you, she find that she is doing it worse. Q: what to look out for, how do you help avoid this problem when trying to vocalise

PJ: Rubber Chicken explanation (explaining problem to some inanimate object can help)

BM: Verbalising may interfere - how do you make time to reflect?

RD: Don't have to pair on everything - fine to go away for a bit and think

Andy P and JF: Don't write code during break, and especially don't make single coding "normal" (or new folks will do all coding separately).

PJ: Go for coffee 4x per day - builds in time for reflection.

Squirrel: Kent Beck keeps drinking water while he pairs, which creates a natural break.

AM: Pomodoro Technique can help. Can put up a sign that says: "You can interrupt us in..."

SM: Use WorkRave, forces you to stop every so many minutes

JF: Empower pair partner to enforce breaks. In general, pair partner is your conscience. Can say "if we were brave, we could check in now".

RD: Research on pair programming: novice-novice, more talking; expert-expert talk less.

Spike M: Qhow to quantify cost and benefits

SM: Microsoft did proper study on TDD, TDD->better code. Anything similar with pairing?

RD: Laurie Williams did most research. Generally with students, not with industrial teams.

JF and RD: ROI studies don't capture sustainability benefits, focus on reduction in defects.

JF: Menlo innovations - Brooks Law not true for them. Can add new people to a project with linear improvement.

Steve F and DS: Connextra, yD fix bug or production code during interview.

PJ: 4 teams no pairing/TDD, 1 with: no-pairing team had 3 or 0 defects, no rollback - other teams 100 defects, rollback

Spike: how to convince managers? Managers OK with two experts pairing, but novice-expert seems to slow down expert because blocked by novice.

DS: code review continuous

Steve F: takes a long time to adapt, different technique. Feel like you're writing on your own with someone bothering them. Given up trying to prove w/metrics. Have proven results but metrics don't help.

JF: Metrics only help justify the decision you've already made

Andy P: Person who knows code isn't available - when this happens, point it out. When pairing, everyone has enough experience to at least make progress even if not expert

Antony M: Blocked by novice? Treating developers like commodities

Steve F: Just sack the novice! Not willing to train them [smile]

Spike: Try reading the code, documentation and asking questions

JF: That is a lie, doesn't work.

DS: At yD, write prod code on first day - good argument for not "wasting time" training

JF and AM (tongue in cheek): But you've slowed down the expert, so fewer SLOC!

Andy P: Who wrote the documentation? A; Expert. AP: If writing the document then could just spend the time pairing & training

PJ: Frequency of pair switching

Andy P, Daffyd: have done 1x/day or 2x/day. Depends on how focussed. If less focussed, many disparate tasks, switching too often makes everyone confused. If everyone really familiar with code and domain then able to switch more often.

Antony M: Complex bad code -> have to load a lot of context -> harder to switch often

RD, Andy P: switch only one in at a time, so one person has the context loaded after switch

AM: Still hard e.g. performance tuning. Also, design decisions not passed on. Use Story Champion who visits pair at time of switch (may not be in pair) but guides feature development

Daffyd: Tim Mckinnon "producer"?

Andy P: Spent long time trying to figure out right names, scenarios, understand feature, improve terminology.

RD: Splitting up when debugging and stuck may be helpful

AP: Injecting a new person can also help get new ideas

Mike H: Resistance to splitting - "we should just keep going" at lunch, then next morning

AP: Need to push back and make them split the more they say this

Kush: at coding dojos, work in threes, switch every 30 mins. Two on keyboard/mouse, one pure navigator. May be helpful for learning really new things.

Antony M: Screwfix put a tester in the triplet, for short periods one person in the triple splits off. (Need 1 tester for every 2 devs, which can be hard!)

Dolan: does it just not work for some people?

Antony M: Someone said "I got into programming because I don't have to work with people - voice shakes, emotional". Tried investigative things, work on his own, didn't work. Found another job.

PJ: 1 out of 10 don't survive agile transform

DS: We filter at hiring time.

AM: May have been marginally autistic, lost value of this person. Could have tried to empathise more.

PJ: Family member has Asperger's - in fact most of us have it to some degree! Worth reading about. Everybody PJ's paired with comes around after a week though they hate it. Confrontational senior developer - helped by working with ball and board (see above).

Mike H: Some people prefer coding on their own, feel it's more productive.

Benjamin M, Andy P: How could you tell whether you're losing something valuable by pushing for conformity?

DS. AM: yD looks for willingness to improve in new people