How to implement pair programming with a distributed team

Ethan Distributed teams, How-to, Pair Programming, Running a business, Web Design & Development 1

Here at 12 Spokes, we’re about as distributed a team as you’re going to find. From Salt Lake City, to Washington DC, to Columbia in Missouri, everyone on the team was recruited for talent, not location. This is awesome because we really can get some great developers on board without uprooting their families and without spiking their cost of living by bringing them to a metropolitan center. However, it does make some common practices difficult to implement the same way we would in a typical office.

One of the big ones is pair programming. Most of us have come from an environment where pair programming was at least prescribed as needed, if not used on a full-time basis; we’ve seen the benefits.

For a while, we went the more traditional route of having every member work on their own project with the occasional code review, and although it worked just fine, I know I felt some deep guilt. When you know that it’s likely you and only you who will look at this code in anything more than a cursory manner, it’s a lot easier to leave in little tidbits that should really be fixed and simplified.

I’d love to think that intrinsic motivation for producing the best product would 100% eliminate such dirty secrets, but empirically I know it’s not true. Although I consider myself a very quality-minded person, I could probably find 40 commits to various projects over the last 5 months that would make you think otherwise.

Based on this acute awareness of internal shame, I threw down the gauntlet at one of our 12-spokes-skype-sessions: “I need supervision!”

We kicked around a few ideas like remote pair-programming using skype and screensharing, but most of the solutions we could come up with seemed to involve a lot of latency and really, our various time-zones would make frequent pair programming a challenge, but we did come up with something. The real thing that we felt would make the difference was that if we all knew that someone was going to read all the code we were going to write. It would make us a little more conscientious. We’ve been sticking to this new process for a few weeks now, and for our team it seems to work.

Presenting Agile-Continuous-Code-Explosion-Latency-Lowering-Extreme-Reviewing-All-The-Time-Evermore (ACCELLERATTE [sic], patent pending, conferences starting in 2013, watch for our certification classes):

The Lore of ACCELLERATTE

1) Every project has a development lead; she architects the codebase and manages the contributions of other devs.

2) Every project has a support person; he is the conscience of the dev-lead.

3) All development of substance is done in your own github fork of the project and pull requests are sent to the main repo under the company github account

4) Every pull request is reviewed by the support person

5) Both the dev-lead and the support-dev have admin access to the company repo (so if the dev-lead really needs to kick something out the door, they can merge and deploy and the support person can still review the pull request later)

6) No one shall deviate from these rules unless it totally makes sense at the time.

Although this is somewhat tongue-in-cheek, this development strategy has really made an impact on what I am and am not willing to release into the master branch of our authoritative github repositories. I know that sooner or later, everything I write will be looked at and judged, and it makes me more careful.

As an unexpected bonus, there’s a lot of knowledge-sharing going on in the github code reviews (which, by the way, are AWESOME, thank you github for such a neat way to dialog within the code itself). I’ve learned little pieces of the Arel API that I didn’t know about before by having my code reviewed, and I’ve learned about some neat tricks and libraries that I’d never seen by reading through the code of others. Many of the good things I remember coming from my pair programming experiences are preserved, but I still get to keep my flexible schedule; it’s a win-win. (Seriously, though, if you use this process you owe us money. I’m just kidding. But seriously).