Remote Pairing

Following on from my first coding dojo, I had an idea that I really wanted to try and push forward. Remote Pair Programming by this, I simply mean pairing up with another developer and working on some code. The key thing being, you are both on your own machine in different locations.

Why Remote Pairing?

The reasons for this are simple:

• It’s flexible – you don’t need to commute, organise a place to go, book offices, equipment – anything.
• It’s cheap – you only really need equipment that 99% of all developers will already have.
• It’s unobtrusive – aside from not cutting into your schedule so much, it also allows you to keep your system configuration (whereas pairing with someone else on their machine means you can lose a lot).
• The focus is the code, not the environment you are working in.

Why NOT Remote Pairing?

• It’s not as personal as working face-to-face with someone.
• Technical issues may arise which cause problems with the remote connection.
• It may require base training in the tools and technologies used (such as Git).
• Things like network latency can be much more noticeable, especially if you are used to a fast pace of work.

My First Remote Pairing Session

So, after a bit of a scout to see who would be up for a remote pairing session, the good Johnno Nolan (twitter) stepped forward as the first available to have a go.

We decided to have a go at Roy Osherove’s TDD Kata 1 since it was scripted and fitted well with our own objectives (I was really interested in seeing how remote pairing worked, Johnno was more into running through the kata and seeing how I worked).

Tools Used

All of the tools we used are freely available (obviously there are some pro things like Resharper used, but they are optional).

• C# and Visual Studio 2008 (IDE).
• Git (source code control).
• GitHub (for remotely sharing the repository).
• MS SharedView (screen sharing – so the navigator can see the driver working).
• Live Messenger (voice comms – we also tried GTalk but it kept crapping out).

Obviously, if you have better tools for any of the above, then please comment and let me know – would be keen to see if we can improve the list.

Getting Started

Now, we were rather slow to get started, and I totally take responsibility for it (two words: Jack Daniels). I woke up a little later than expected and was rather unprepared so had to go through some configuration and setup before we got started.

That said, I would strongly recommend that BEFORE the session you:

• Create a Git repository on GitHub and setup all required parties as collaborators. Then make sure they can push/pull to it.
• Have a quick chat before hand and ensure SharedView and Live Messenger are working good. This could also be a good opportunity to create rough plans and mockups for what work is to be completed in the pairing session.

How We Did It

1. Started working our way through the kata. First driver creates a failing test and then makes it pass.
2. Driver then performs any desired refactoring.
3. Driver then hands to navigator, who then becomes the driver themselves, they then right a “confidence” test. This ensures that 1) the code is definitely good and 2) they have a good understanding of why the code is working that way.
4. Go back to point 1. Rinse and repeat until the code is “to spec”.

Now, that said, we originally did start with the standard “red, green, refactor” and just bounce back and forward. But we found ourselves naturally discussing what we had done as we “passed the torch”. This then meant that we would often think of new tests and add them. We ended up calling these “confidence tests” since they boosted our confidence in how the code was running.

I found we did spend a long time discussing things – but I think this is mainly because we have never worked with each other. There is a lot to take in, but also a lot to put out. You are no longer hacking away on your own – you need to justify this code that you are writing to someone else now. I think as you get used to work with people, you begin to understand their style etc. Even though we spent a long time discussing, I felt all of it was healthy.

Summary

• I really enjoyed the session and engaging with someone who is obviously passionate about their code.
• SharedView really did shine, it’s very quick and simple to use and the fact that it auto-closes other sharing sessions when you begin sharing makes “passing the torch” a lot quicker.
• Git is awesome! Pushing/pulling the commits back up and down is so easy. We aren’t here to mess about with source control, we want working code!
• I feel pairing is a great way to work & ends up in very clean code. I was more than happy with our (albeit simplistic) resultant code. Especially since at times it “felt” like I was hacking, but once we discussed, we determined it was actually a good, pragmatic call.
• When passing the torch, get back to coding quickly – we often paused to chat and lost our focus.

I am really keen to keep these kind of sessions going – so if you are interesting in doing something, then please comment, or contact me on twitter!

Johnno has posted a great article on his blog over here – be sure to check it out!