Table XI
Published in

Table XI

Pair Programming

Truinboy: https://flic.kr/p/5pkYiv
  • A large team. About 15 to 20, if I recall. Pairing on small teams, like under five, is very logistically challenging. You’d think that a two-person team would be perfect for pairing, but in fact, you’re bound by the limits of both person’s schedules. A larger team gives you more flexibility in the face of meetings, sickness, and other responsibilities.
  • Neutral pairing stations. Nobody was pairing on their own laptop, there were dedicated computers with dual keyboard and mouse setups and a common configuration. This is, I think, a huge and underrated issue. When pairing on one developer’s idiosyncratic setup, you have a situation where that developer is always the more comfortable of the pair, plus you have that developer’s email notifications or whatever as distractions.
  • An environment where noise was okay. Another underrated issue. Pair programming requires developers to talk to each other, and as a result, it’s loud. This is fine if everybody is doing it and everybody understands it, but if you are trying to be a one-off set of pairs in an open office where everybody else is quiet, you’re going to stick out and that’s going to feel very awkward.
  • Dual story responsibility. The story tracker was customized so that the pairs had dual responsibility and source control commits were made jointly by the pair. This is a little hard to do (though the tools have gotten better), but critical to maintaining an understanding of who was responsible.
  • Pair rotation. The team had a very strong cultural norm that pairs should not last longer than a couple of days. This was actually very useful in knowledge transfer, and made sure that people tended to work with all members of the team. If you are on a team that pairs heavily, I do recommend rotating regularly.
  • No remote culture. The team did not encourage or support working at home much, and didn’t invest in technology to support remote pairing.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Noel Rappin

Noel Rappin is an Engineering Manager II at Root Insurance. He is the author of Modern Front-Front End Development For Rails. Find him @noelrap.