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: 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
