Two Guys Arguing

(Additional) Notes on Remote Pairing

Posted in software development by benjaminplee on 09.02.10

Stuart Sierra of Relevance posted a nice article on their difficulties with and tips for remote pairing.  A few of my thoughts are below (and in a comment on his original article):

My current client was my first experience with remote pairing (local team of developers remote pairing with equal number of client developers). Overall things went much better than I expected however the communication bandwidth difference between remote and local is VERY apparent and a huge loss. Most of the time we try to set up cross-company pairs which benefits reducing knowledge silos, but increases communication costs.

Per the client’s request we have been using Microsoft Communicator with decent success. Lag is an issue but luckily both companies have adequate network speeds to make up for it. Working on a thick-client Windows application means no to terminal work but I will definitely look into tmux and NX next time.

The biggest disadvantage of remote pairing is the loss non-verbal communication and flow. I am a firm believer in the value of pairing in all but the most trivial of tasks, but haven’t been able to muster the same level of interaction over a headset. All of my best development/pairing experiences have been working with a pair which I was “in tune with”. The non-verbal communication (e.g. grunts and quick points) and fluidity (taking quick breaks for a drink, answering a question for another dev in the war room, etc) were the key to our productivity and happiness.

One of the biggest technical issue I have found is war-room spacial awareness while STILL hearing your pair clearly. A high quality headset (mic and earphones) is invaluable when working remotely, but this limits your “presence” in the war room. Side conversations get missed or get replaced by more “formal/slow/inefficient” means of communication. Find a solution to that, and things would be much better.

Pairing is not easy in the best of conditions.  It is so easy for one or both developers to wander off (mentally or otherwise).  On top of convincing developers to open themselves up for constructive criticism and constant communication there is always the adventure that is convincing the business side of things that the “extra” expense now is worth it tomorrow.

Despite all that, it is worth it.  Pairing keeps me pushing myself to work harder/faster/better and leaves no room for bad habits and poor choices.  My first day at Asynchrony I paired for ~8 hours with a great developer and promptly came home to my wife and collapsed.  She, being the loving wife she is, was concerned my first day had gone poorly.  I said no.  Great in fact.  I wrote more high quality code that day than I had in the past month working in a cube by myself.  My brain was just dead tired.

</end psuedo-rant>


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s