Remote Pairing - a quick guide

Image by PhotoGraham 

Today I spent most of the most of my morning and afternoon honing my TDD skills with Rob Cooper. Whilst none of the work we did was particularly earth-shattering it was great to delve in code and discuss at length. We tackled a TDD Kata in depth rather than discussing the 'form' elements we concentrated on discussing how the design emerged and the different approaches to testing. We had a few technical issues and ironed most of them out but I wanted to outline the setup as it seemed fairly easy to arrange.

Remote Pair Recipe

• IDE of choice - (helps if these match)
• Git - (or other DVCS)
• GitHub Account - (or other hosted service)
• Skype/GTalk/Live Messenger - for Audio Comms
• MS SharedView - see what the other pair is doing

MS SharedView deserves a special mention here as it worked extremely well for screen sharing.

Guidelines

Check your setup

Before starting make sure you can both access and commit to Github. This is the place where you are both going to be passing your code back forth to. Make sure your equipment works (someone in this pair had a crappy mic in his headset - no names mentioned (*cough* - me)). This slowed us down and upset flow a little. Thankfully the other pair was not blameless. If you are going to use other tools agree what they are, including version, before the event so you don't have to spend time scrabbling around the internet for requisite software.

Have a plan

Do not go into a session unprepared. Without a plan a session will lose direction. I think we were over-prepared with things to do but its better to have more than less.

Don't be scared

Having someone watching your every keystroke may seem like a daunting thing but hey you can always have your revenge when its their turn to drive in general you are both here to write better code so if you make a mistake and your pair notices it or if you have a bad habit you should be grateful it is being pointed out. That way you can fix it.

Don't be offensive either

There are many ways to convey that your pair has not removed the duplication in that class other than by comparing his intellect to that of an amoeba. Pick a nicer one.

Swap driver-navigator often

Rob and I swapped mid-scenario in our TDD session. I would red-green (to the simplest possible case) then Rob would grab the session add a further test and refactor. We thought this was a nice way of doing things as we both had our input in creating the feature. I would make the fixture and pass it over to Rob as tested. Rob double checks with a further scenario and makes the call to refactor.

Embrace your differences

Rob and I had a slight difference in our approach to testing. We stopped and talked about it afterwards but it was not a problem in this case as the code was 'throw away'. The issue may have been more pressed if we wanted to keep the code.

Take breaks

I'm ashamed to say that even though Rob and I are both Pomodoro Technique practitioners we took 1 break in the multi-hour session. This was wrong. I found that towards the end of the session I was losing concentration. With pairs I think this especially important due to the intense focus you have with two of you.

Workflow

We approached the exercise like so:

1. Driver picks feature
   
2. Driver writes test.
3. Driver passes test.
4. Driver commits and pushes to GitHub
5. Navigator pulls from github
6. Navigator becomes Driver
   
7. Driver adds 'confidence' test and refactors.
8. Go to 1.
   

As mentioned above this did have a nice side effect of us both touching the same features and meant we swapped often. The code was clean and I hope we both got as much as I did out of the exercise. I'll certainly be doing this again.