The article glances over a lot. We pair-program on production code over 95% of the time. Driving duties alternate every few minutes or even seconds. Pingpong programming is common. It's all facilitated by having dual keyboards and mice hooked up to the workstation. Occasionally the pair splits up virtually. Each half of the pair has their MBP sitting there on the desk next to the 30" shared workstation monitor. If the driver is taking care of a mindless task (just typing) then the non-driver can switch their attention to their own screen for whatever, but still be aware of what the driver is doing. Examples of windows you have open on your MBP while pairing are: Harvest for details time-tracking, Campfire to communicate with stakeholders and other devs, pivotaltracker to refer to story details, API references, etc.

On the people front, we do our best to only hire experienced devs that will like the culture and fit in. We're a boutique shop, so we can be very picky about who we hire. Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but don't hire apprentice or junior-level folks. Occasionally we do extended pairing matchups with client developers in our office, but they have to fit in culturally for it to work.

I think pairing all the time is one of our most important competitive advantages. My teams produce some of the highest-quality code I've ever seen in 15 years in the biz. We are able to effectively leverage XP-style client acceptance in our process because our code is so defect-free.

I'm proud of what we've created at Hashrocket, but usually try to stress the importance of context and talent in making it work. Pairing all the time is one of those things where I have to advise Agile idealists that it probably won't work for them. :(