Difference between revisions of "Pairing Techniques"

From CitconWiki
Jump to navigationJump to search
Line 117: Line 117:
  
 
'''PJ: Frequency of pair switching'''
 
'''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

Revision as of 03:51, 6 November 2010

Live scribing - will update and tidy up later

Andy Parker: driver-navigator sitting back person has to have a notebook, bigger picture, what's the list of done criteria - list gets bigger and bigger driver thinking about next thing to type Need to agree when you're switching

AP: can be good when skills unequal

ping pong 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

Jeffrey F: designed and 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 fails or 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, don't make it the usual way (or new folks will do all coding separately).

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

Squirrel: Kent Beck's drink water method

AM: Pomodoro: "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