Remote Pair Programming setup

For a few years now I have been looking for a solution that allows two or more people to share an editing session who are not sat side by side.

Each OS has its own preferred way of sharing a desctop/workspace for collaborative working. Some work cross platform (e.g. VNC) and some work via the internet (e.g. GoToMyPC). But for much of my daily work I want a nice fast way of sharing the code that I am working on with a collegue. One or both of us are likely to be behind firewalls, proxies and all sort of important security that makes collaborative remote working so very very hard.

On my current project we are using Eclipse as our development IDE, a local IRC server for ad-hoc team communication and point to point instant messaging. Backed up by Skype for person to person video and occasionaly more traditional email and phone for that personal touch.

All in all this is working fiine and I have to admit I had forgotten how useful IRC is in comparison to IM when it comes to team working. Just having everyone aware of the conversations that are taking place can be a real boon.

I had some spare time last evening and decided to see if I could track down a viable solution to the remote pair programming. Confining my requirements to either complete desktop sharing or Eclipse based paring helped quite a bit because the other added complication is that we have a mixed OS development team including Windows, Linux and Mac OS X. The number of OSs is likely to settle down to just two but at the moment we have quite a mixed bag - which is actually quite refreshing.

So back to the remote pairing issue. I quickly realised that sharing the editing session is likely to be sufficient to our needs and that other tools could provide text, voice and video quite effectively and did not need to be replaced.

My first efforts involved the Eclipse Communication Framework (ECF). I had played about with much earlier versions and concluded that it was a little fussy and difficult to work with for my tastes but decided to give it a go. Working behind a proxy with limited ports meant setting up and running a local server.

I can see a lot of promise in the ECF but it just feels far to heavy weight. I might have made some errors but I could not get it to work, connecting to the server seemed ok (although there were a lot of stack backtraces on startup - now I really cant understand why people still dump these things to the console with the idea that users - even developer users will have a hope of understanding what went wrong. With 3 pages of small text flying past it is just too easy to spot the line that tells you what when wrong. So after an unhappy hour or two trying to get two instances of Eclipse to open a shared editing setting I gave up and went back to searching for alternative.

After a little bit more searching I cam up with XPairtise and open source project that seemed to do exactly what I now wanted - share an editing session. Unusually for an open source project the documentation is pretty good although it was early in the morning and I almost missed that there are two downloads; one for the eclipse plugin and the other for the server.

The setup which I eventually came up with involved the XParitise server and Eclipse running natively on my Mac and a Ubuntu VM mimicing a remote pair. The server is nice and quiet just reporting that it is up and running - a refreshing change. After setting up accounts through the Eclipse preferences pane (a little quirky on the UI the first time around) but it was heart warming to receive the 'account created' message.

Getting the shared editing session to work took some time. First when creating a shared workspace all the files from the project are shipped up to the server. When joining the shared workspace again the project files are brought down so take heed of the backup dialog or work in a different Eclipse workspace for shared working.

It took at least 2 Eclipse restarts to get the shared editing to work and there is a note on the XPairtise site about using the eclipse -clean option to refresh all the plug-ins

But after this initial setup headache I have a configuration that will allow remote pair programming.

Result!!

Update: I have just rerun the setup within a distributed team (2 locations) and after a bit of a lag in synchronising the project contents everything worked fine with 3 concurrent users (Driver, Navigator and Spectator).

Keep the story wall clean & tidy!

Like so many artefacts produced and consumed during a software project keeping them up to data and simple is vitally important.

For an agile project where the aim is to keep the number of such artefacts as low as possible this should be straightforward but it is easy to let this sort of project hygiene slip. After all if everything is working well the cards only live for a short time, they collect data during the iteration and perhaps into testing but after that they are of little value. If they live for such a short time why is it important that the cards be written clearly, identify where they came from for traceability etc.

Keeping the story cards clean helps the team by reducing the number of times related information is sought. For each discrepancy between the card and its context someone needs to work out what the differences are, if they are important and what should happen. By not reflecting this on the card as a simple note edit it is likely that someone else will need to go through the same process.

It is arguable that if this situation arises that the stories are too big and the cards are spending too long in development. I like to make sure that each story is a coherent vertical slice of functionality with a starting point and user visible result. Sometimes it is not practical with this constraint to slice the work into a story that is both quick to implement and satisfy the requirement to deliver a useful and visible result.

It does and should not take much to keep the wall clean. If it does then story wall hygiene is probably not your biggest problem.