I’m not a fan of continuous paired programming. There are a few cases where it makes sense. (i) new employees, (ii) rookie programmers (iii) certain rapid development cycles. However, sustained two users and one keyboard is simply not practical unless it’s full contact MMA style.
There are a few other interesting offshoots. (a) Real-time file sharing (see subethaedit and coda) (b) splitting the coding into dev and test but coding in parallel and together. This can be even more fun when you add a third person who it structuring the module’s API signature while the others fill in the blanks.
Pair programming is not meant to be arm chair programming or back seat programming.
Belden
2012/09/18 at 06:46
The traditional navigator/pilot model of pairing easily leads to detachment or keyboard bickering. The easiest way we found to make full-time pairing sustainable when I was at AirWave.com was to simply plug in another keyboard and mouse.
Without resource contention, it’s easier to fall into more productive pairing roles than navigator/pilot. The navigator/pilot model doesn’t really work when pairing people who have years’ difference of exposure to the project: eventually the senior person grabs the keyboard and starts working as an observed singleton.
It’s a lot harder to shut out your pair when they have equal control over the computer.
Richard Bucker
2012/09/18 at 13:16
Since you commented I started thinking about it some more. I think the only pair programming I would find comfortable or useful would be something similar to battleship and not etch-a-sketch.