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, which 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 says that in novice-novice pairing, there is more talking; expert-expert pairs talk less (see ball and board above).

Spike M: Q: how to quantify cost and benefits

SM: Microsoft did proper study on TDD, which concluded it led to 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 ("adding more programmers to a late project makes it later") is not true for them. Can add new people to a project with linear improvement.

Steve Freeman and Douglas Squirrel: Connextra and youDevise fix bug or work on production code during interview.

PJ: Case study: 4 teams with no pairing/TDD, 1 with pairing and TDD. Pairing/TDD team had 3 or 0 defects and no rollback - other teams 100 defects, had to rollback after going live.

Spike: how to convince managers? Managers OK with two experts pairing, but novice-expert seems like it would slow down the expert because she will be blocked by the novice.

Squirrel: Call it a continuous code review.

Steve F: takes a long time to adapt as it's a different technique. At first, feels like you're writing on your own with someone bothering you. Given up trying to prove with metrics. Have proven results over and over but metrics don't help.

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

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

Antony M: "Blocked by novice" - makes it sound like managers are treating developers like commodities.

Steve F: Just sack the novice! It appears we're not willing to train her anyway [smile].

Spike: To train, we can try reading the code and documentation and asking questions.

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

DS: At youDevise, new staff write production code on the 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; The expert. AP: Instead of writing the document and updating it regularly, 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 leads to having to load a lot of context, which in turn makes it 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 suggests the idea of a "producer".

Andy P: Pair who start a feature have spent a long time trying to figure out right names, scenarios, understand the 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 same thing 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 was shaking, person very 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. We lost significant value this person could have contributed. 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: youDevise looks for willingness to improve in new people