Back in 2005 a pair of Stanford students asked me if they could observe the pair-programming environment at the company I was working for. They were working on a project to challenge the notion that two people pair-programming had separate roles of “driver” and “navigator” a common notion of how pair-programming should work at the time. Back then, we had a traditional pair-programming setup: 1 desk, 1 keyboard and mouse, 1 computer and (of course) 2 people. What they observed was downright painful!
As one example, they recorded a session where someone was verbally dictating syntax and keyboard actions to their pair:
Hugh: So… Ilya: Parenthesis. So percent, getNewArgs… [Hugh types.] Exactly. So save off those two lines in the new method. Hugh: Uh… Ilya: Right…down, down, down, there we go. Hugh: So we… Ilya: So, percent getNewArgs equals percent args [Hugh types this line to terminal.] Uh, I think that’s it. Hugh: This? Ilya: Yeah, that’s all we want to do. Get rid of the blank line and close the new.From a pair programming session revealing the perils where one person “drives” while the other “navigates.” Excerpt from “The Social Dynamics of Pair Programming“
This was clearly the wrong way to go about pair-programming. “Driver” and “navigator” was turning out to be closer to “driver” and “back-seat driver” and like all experiences of back-seat driving, it could be frustrating for the driver, and generally unproductive. What we’ve found at Engine Yard is that it’s far better to optimize the pair-programming environment not for a “driver” and “navigator,” but for co-programming.
Jon Crosby and Ezra Zygmuntowicz pair-programming
A good co-programming environment should reduce the friction for any task, and has three rules:
- Create a shared environment, where the pair can fully immerse itself in the problem at hand.
- Make it easy for a member of the pair to ‘fork’ off and not interrupt flow.
- Remove any obstacles that get in the way of completing each other’s syntaxes sentences.
The Engine Yard Pair-Programming Setup
Two keyboard and mouse sets: This alone dramatically improves a pairing environment. Often we see one member of the pair ‘hovering’ over the keyboard — a non-verbal cue indicating that they want to take over. It’s amazing how effective code can be in expressing an idea over a verbal description or notepad sketches. No more oral syntax descriptions!
Dedicated pair-workstations: Identical workstations with identical configurations, including editor. We use iMacs with nice big screens. Similar environments make it easy for pair switch-up. Everyone is familiar with the environment on the pair-stations, so there is no re-learning a new environment depending on who you happen to be pairing with.
3-Computer Setup: Each pair brings their laptop to dock alongside the pairing station. This enables any pair to perform research, and kick-off long running processes, without losing context on the dedicated workstation. While it takes more discipline to stay on task, we think it’s worth the flexibility.
I don’t claim that this is the perfect environment for all situations; but it’s something that works well for us.
Loading ...
What IDE do you folks like to use in this environment?
We customize emacs. Two people on the team (both happen to be named Sam) push the customizations. See: Sam Merritt's http://github.com/smerritt/spiffy-elisp/tree/mast...
Also check out Sam Tesla's recent post showing how emacs can be used to create a programming environment: http://blog.alieniloquent.com/2009/06/25/an-examp...
Dual keyboards and mice also help avoid the "passing around the head cold" problem we had before those Stanford students came in. Keyboards are the least sanitary thing on the desk.
Indeed it does! Also, keep a bottle of sanitizer handy!
a multi-cursor editor would be really nice for this.
We at one point experimented with n-brain's una (http://www.n-brain.net), but it didn't fit our needs at the time. You might want to check it out.
This is delicious!
Fascinating. My first experience in pair programming turned out to be more like "teacher" and "student", which I found very frustrating since it slowed us (me) down tremendously. I shut it down when the other individual began to just be "along for the ride".
Since then, I've found that programming together is a great way to get a new team member up to speed on a project, but it's not pairing.
This looks absolutely fantastic. I've done some pair programming in the past, and found its effectiveness to vary wildly. With my first experience with pair programming, we did the two keyboards, two mice thing, but the dynamic of it ended up with the "navigator" frequently struggling to stay awake. Subsequent experiences were often crippled by one half of the pair being vastly more experienced than the other, which resulted in absolutely massive losses in productivity. In other cases that went well, code quality was dramatically improved with roughly equivalent productivity.
Take-away is that pair programming is heavily dependent on experienced, motivated individuals and a great setup. When it fails, it fails spectacularly, but it can also offer great gains if the company is committed to making it work. I have strong doubts that many people get pair programming right the first go-around.
[...] http://www.engineyard.com/blog/2009/pair-programming-should-be-co-programming/ : un billet sur le Pair Programming [...]
This looks like a great setup.
What toold do you use to share the control on the pairing workstation? Plain VNC, something like Synergy maybe?
Thanks,
Peter Provost blogs about "The Pair Programming TDD Game" at http://www.peterprovost.org/blog/post/The-Pair-Pr... He describes a single-keyboard technique that works, and is fun as well. (I saw him demonstrate this at Agile2006, and have been using it ever since.)
Correction: That link is http://www.peterprovost.org/blog/post/The-Pair-Pr...
Pretty cool post. I just stumbled upon your blog and wanted to say that I have really liked reading your blog posts. Anyway I’ll be subscribing to your blog and I hope you post again soon!
Nice writeup, this is one of the problems we have been observing in our current project (driver, navigator). in a pair one used to instruct line by line and partner just pick them up and write in a code.
moreover we haven't found it working properly, definitely we are doing something wrong or not having right pair. currently we have been planning to split the ownership within the partners, one partner will take the responsibility of the story (backlog item) and another partner will take the responsibility of getting it properly spec oriented (acceptance test case).
because we found later our testers have to give more effort to make those verified according to the spec. testers can't manage time to discover new issues rather they engage themselves to verify those specs.
this is just a thought we have been planning to implement pretty soon.
best wishes, tekSymmetry LLC.