I must confess I was somewhat sceptical about the effectiveness of the Pair Programming technique, but that is mainly down to my lack of experience of it. My initial reservations were the obvious. Why have two people do the work one could? It seems both a waste of time and money. I also questioned how much value a seasoned developer could get out of it – certainly for a newbie like me the experience would be invaluable, although even here I would worry that a) I would struggle to pull my weight and b) be embarrassed about my lack of knowledge. With this in mind I visited the Sky SNS offices in Brick Lane, where they are big advocates of Pair Programming, to find out more.
The development teams at Brick Lane use Pair Programming for everything, in conjunction with Test Driven Development (TDD). The general format is that one developer writes the test for a function (based on the acceptance criteria of a story card), and the other then writes the code for the test. As the code is initially meant to fail its test, it is then up to that coder to try to write the code in a way that it will pass the test first time, so that the first developer will have to re-write the test in a better way – hence both developers push each other to get the best possible code.
It is certainly not true that two people working on a task will complete it in half the time one would, However, pair programming is more efficient in the long run. Two people means two pairs of eyes to spot errors. This saves on a later code review, and is more effective anyway as it happens in real time. So before you check in any code, you already know that it is of the highest quality. This means that it can go into production with a substantially lower risk that it will later break. As it is much cheaper to fix errors at the development stage than when the product has been released, this can save a significant amount of money down the line.
Pair programming increases productivity as developers are inspired by each other. This encourages creativity and stimulates discussions on the best way to do things. As a lone developer, when you have a problem, chances are you struggle to solve it yourself for a while, then ask another developer (who is working on their own code) for help. You then have to spend some time explaining the problem so that they can understand, and then they have to spend their time helping you fix it. You then both have to get back into the ‘coding zone’, which can take up to fifteen minutes. (There are a bunch of interesting articles on this – see http://www.doolwind.com/blog/how-to-get-in-the-zone-and-stay-there for a starting point) This is a lot of time wasted. In pair programming you are both already focussed on the same thing and can bounce ideas off each other as you go along. For the seasoned developer there is the chance to see things done through fresh eyes, and for the newbie there is massive scope for learning, and learning quickly. Rotating developers in pairs means that everyone gets to benefit from everyone else’s experience.
You are also less likely to spend time off-task, browsing the internet etc, because there is someone else beside you to motivate you. In true Agile spirit, ownership of code is shared among the developers in the team, so that no single person is accountable for breaking a build (although of course with two people co-working on a feature there is very little excuse for checking in code that will break a build). Moreover shared ownership means that if one developer is off sick, work can still function as normal.
Of course pair programming does have its limitations. Coding is meant to happen at the rate of the slowest developer in the pair. This can be substantially slower for a new starter than someone who has been coding in a certain language for years. It is important this does not end up with the less experienced person simply sitting and watching the other write code. As a technique it is perhaps better suited to larger teams with more developers, although this is not to say that it cannot work in small teams, just that it requires more investment and faith that the extra time tasks take, will be worth it because of the high quality code that is produced.
From my point of view, it is certainly a technique I would like to try during my time on the Technology Graduate scheme, and think that a lot can be learnt from the guys at SNS and how they work. Whether or not the pair programming technique would work as well in other areas of Sky is uncertain, as some areas still work with Waterfall type frameworks. What do other people think about Pairing – do you use it and if not, could it work for your team?