Difference between revisions of "Pairing Techniques"

From CitconWiki
Jump to navigationJump to search
Line 68: Line 68:
 
PJ: Go for coffee 4x per day - builds in time for reflection
 
PJ: Go for coffee 4x per day - builds in time for reflection
  
AM, DS: Pomodoro technique, Kent Beck's drink water method
+
Squirrel: Kent Beck's drink water method
  
 
AM: Pomodoro: "You can interrupt us in..."
 
AM: Pomodoro: "You can interrupt us in..."
  
 
SM: Use WorkRave, forces you to stop every so many minutes
 
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.

Revision as of 03:41, 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.