Writing software can often be a pretty solitary task; however much conversation and collaborating went into the conception and planning of your software product, the business of knuckling down and writing code tends to be done by individuals often working in isolation much of the time. At first glance, this makes perfect sense - It's easy (and good practice) to split big software projects into smaller, interconnected modules (which is great for easy division of labour).
Therefore, for most people, programming is an activity that's best done with headphones on and head down, away from the distraction of working with others. However, by taking this approach, we miss out on many of the advantages that working in a more collaborative fashion can bring. As with many kinds of work there are many advantages to this - the potential for knowledge transfer between workers, for one, in addition to the obvious decreased likelihood of errors that comes from having two or more minds engaged with a problem. However, in addition to these general advantages, there are specific aspects of software development that make collaborative working an even more compelling proposition, leading to the development of a methodology known as Pair Programming.
Pair Programming requires two programmers to constantly work together, at one computer - one of them 'driving' while the other observes, and continually discussing the work that they're doing. The two swap positions frequently, to maintain concentration. As well as fostering all the general benefits of group working described above, this also allows one programmer to concentrate on the strategic direction of the work, while the other focuses on the details. This provides an invaluable safety net against bugs, poor design decisions, and many other problems that build up 'technical debt' - leading to increased development costs later in the lifecycle of the product. In addition, it ensures that more than one person knows the intricacies of that part of the system, so no mysterious secrets about the workings of our product are forever archived away inside the brain of one person.
At Harmonypark, myself and Chris have been experimenting with pairing for a few months - not all the time,but on any piece of work that's particularly complex. This has gone really well, as a new recruit here, it's helped me get to grips with the codebase of our products, and in return I've brought a fresh perspective to the work we're doing which I think has been valuable.
However, our colleague Andrew was initially left out of our experiement, as he's based in Glasgow, and works remotely - this is a great pity, as pairing is particularly great in precisely this situation. By keeping the lines of communication open between the London HQ and Andrew's HPK Scotland outpost, we get better access to another formidable brain to throw at tricky problems when they arise, we get to share skills, and Andrew is more involved in the day to day business going on around the office. Luckily though, with the aid of a few bits of software you're probably already using, it's actually very easy to pair-work remotely. Having given this a go, we've been thrilled by how well it's gone, and thought we'd share some information about how we went about it.
To start with,you'll need Skype, or some other VoIP software, for voice communication between the two pairs, and probably a pair of headphones for anyone who's going to be remotely pairing from an office where other people are trying to work. This is the easy bit, so I won't go into any more detail at this point. The next thing you have to sort out is some way to allow the 'driver' to share his or her screen with their pair, so they can both see what's going on. Skype has built in screen-sharing, which is great if you want to get started quickly, but it eats bandwidth as it's essentially a video feed of your Desktop, and, crucially, doesn't allow the 'observer' to take control of the computer, leading to faffing when he and the driver swap places.
Better, marginally, is a tool like VNC, which allows remote-controlling of a remote computer. Again, this is bandwidth intensive, and requires a not-insignificant amount of time to set up. It does allow both pairs to control the computer when required though.
However, still better yet, in our opinion, is the solution that Andrew and I eventually arrived at. Both being users of Vim (I'm a recent convert) for text editing - we only really needed to share one terminal session, rather than the whole screen. Given that this is just text, the bandwidth requirements are orders of magnitude lower than screen-sharing a GUI environment, and can be achieved with tools that are installed on any computer with a unix-ish operating system (OSX and Ubuntu Linux in our case) by default, and taking less than 5 minutes to get up and running. At the centre of our solution is the amazingly useful GNU screen utility, a 'terminal multiplexer' that allows you to run multiple shells at a time and switch between them, disconnect from running shells on local or remote machines and leave them running, and crucially, to have multiple users log into the same shell simultaneously. So, to get started, you have to do something like this:
The person whose computer is going to be used needs to ensure that ssh and screen are installed on their machine, and that sshd is running, that port 22 on their machine is accessible from the outside world (this may well require tinkering with firewalls, and/or port forwarding rules on your router or other network hardware). In addition, there needs to be a user account on that machine that the other pair can use to login. Once all this is done, the remote pair should login to the computer over ssh.
Next, one or other programmer has to start up a screen session which the other can connect to. 'screen -mS pairing' will create a new screen session named 'pairing', then '<ctrl-a>:multiuser on' inside that session will switch on multiuser mode, so that the other can connect. Finally, the other user simply connects to the shared session using 'screen -x pairing' (If you're already familiar with screen and wondering why we're using -x rather than -r , it's because we are connecting to a currently active session, rather than reconnecting to a detached one). Now both users are connected to a shared terminal session from which the driver can launch their text editor of choice and get to work!
On the whole,this setup worked fantastically for us - Working together, Andrew and I got some quite complex problems solved far quicker than either of us could have done alone, as well as sharing valuable knowledge about the codebase, and various vim tips and tricks. We found it useful to have multiple screen sessions running (easily achievable by repeating the instructions in the paragraph above with a new session name), so that we could run tests in one while working in another. We were up and running in less than 5 minutes, and only faced one setback of a technical nature - with Andrew on Mac OSX and me on Ubuntu Linux, there were some odd character encoding glitches now and then, but nothing insurmountable at all. In fact, the biggest blocker to productivity was our tendency to meander slightly, perhaps due to the novelty of working in this manner. In any case, we still found that pairing offered a great improvement in motivation and productivity, as well as a valuable line of communication with the rest of us for Andrew up at HPK Scotland.