In the Defence of Pair Programming
A few weeks ago I read an interesting article challenging the practice of Pair Programming. I’ve written about Pair Programming before and how I think it’s pretty awesome.
Greg Young pointed out that this is actually just an opinion piece and none of the numbers are supported by actual research.
One of the problems with an article like this is that it tries to measure the value of Pair Programming. The problem here is that many of the benefits of Pair Programming are very difficult to measure – for example, how do you measure the value of having better communication between your developers? Or the value of better code consistency? Can you assign a dollar value to higher code quality?
I have found Pair Programming to be immensely beneficial to my programming habits – pairing with strong developers is one of the best learning opportunities available and I would always prefer that to working on my own.
Should we always pair?
That’s not to say you should pair 100% of the time. There are plenty of activities which are not conducive to pairing – doing research on a topic, for example. It takes experience to recognize situations where pairing is not going to be effective, raise it, and take the appropriate course of action.
Having said that, I can also see the value of having all developers on a team pair 100% of the time. For example, many developers don’t want to pair – they prefer working by themselves for whatever reason. Unfortunately these are usually the developers who benefit most from having a pair! Having a blanket rule of 100% pairing for all developers can be the lesser of two evils in this scenario.
Not everyone is a good pair
This article also ignores the fact that not everyone is a good pair. In fact, I would argue that pretty much everyone suck at pair programming when starting out – it takes time and experience to generate the maximum value out of pairing.
This is something I try and work on every single day: making sure my pair understands the code we are writing, making sure I don’t hog the keyboard, making sure I don’t force my way of thinking on my pair. It takes time, but it’s absolutely worth it.
Once you get into the habit and you’re in a good rhythm and doing ping-pong pairing you’re going much faster than either person could manage on their own. Plus you get the immeasurable added benefit of having multiple developers sharing context on the same part of the codebase.
In case you haven’t come across this term before, ping-pong pairing works as follows:
- A writes a new test and sees that it fails.
- B implements the code needed to pass the test.
- B writes the next test and sees that it fails.
- A implements the code needed to pass the test.
Measuring Developer Productivity
I don’t have a magic way to measure developer productivity, but I know for a fact that measuring developer productivity in lines-of-code per hour is a terrible, terrible idea.
“Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” – Bill Gates
Code reuse, refactoring, removing dead code and comments – all of these will produce less lines of code and a cleaner, better solution. Bloated code, not-invented-here syndrome, code duplication – all of these will produce more lines of code.
Which one do you want?
The benefits of pair programming are simply too great for us not to be doing it. Happy coding.