Pair programming brings a great many benefits to a team that’s truly mastered it.
Those of us who are lucky enough to have experienced working on a really effective XP team know about that almost magical thing that starts to happen when the barriers between different members of the team break down, egos and code ownership are cast aside, and the team starts to evolve the codebase as one, mighty, coding machine. It’s truly a joy to be a part of, or even just to watch.
When I worked at the BBC, we tried various experiments with different styles of pairing and retrospected on them regularly to figure out what was working. We went from the extreme of the same pair working together right through a whole story, sometimes staying together for a whole iteration, to switching up pairs several times a day. In the end, of course, we found a sweet spot somewhere in the middle, and seemed to know intuitively when a pair was going stale and needed a fresh injection of energy by changing up the members.
Compare this ideal with this description of “Total Football” (that’s ‘Soccer’ for those of you speak US English!)
“Total Football” is the label for an influential theory of tactical association football in which any player can take over the role of any other player in the team. It was pioneered by Dutch football club Ajax Amsterdam.
In Total Football, a player who moves out of his position is replaced by another from his team, thus retaining the team’s intended organizational structure. In this fluid system, no player > is fixed in his nominal role; anyone can be successively an attacker, a midfielder and a defender.
Regularly rotated pairs of programmers are essential in developing this kind of fluid self-organisation within a development team. While specialisation may become important for larger teams, there’s no doubt that keeping the whole team familiar with the whole codebase for as long as possible brings huge benefits.
For me, the biggest, and often the least mentioned of these benefits is that the team develops a kind of shared consciousness about the code and how they conventionally like to work with it. Not only does this mean the team can move extremely quickly, knowing exactly where to find something and how best to hack on it, but it is a stake through duplication’s dark and twisted heart: “Didn’t we work on something a bit like this last week, Brett?”. Once a team starts to think and communicate together this effectively, code re-use goes through the roof as common problems are solved in consistent ways, patterns emerge and are factored out for re-use.
You can probably tell, I’m a massive fan of pair programming, mainly because I absolutely love being this effective in my day-to-day work. How about you, loyal reader? What are your experiences with pair programming? Have you tried it? How was it for you?
We used to do pair programming quite a bit when I started working at Laszlo and there were just two of us on the core client-side team. At first it was just an efficient way to learn. Then after I came up to speed in the code base we would do it whenever things were tricky. I don’t hear people talk about it much, but I am quite fond of ‘pair debugging’ which I’ve found to be a very efficient way to isolate a bug when there is time pressure to fix it. I believe there is something about the social interaction which opens up new pathways of thought. There’s a bunch of research in educational theory to support that about how we learn at a higher level when interacting with other people.
I also agree with your point about the value of shared consciousness, which we more commonly achieve through peer code reviews. It seems to me that good code is typically a result of it being well-loved.
Absolutely! The paper referenced at the top of this blog post by Steve Freeman contains, amongst other interesting things, some discussion about cognitive science research suggesting that the ‘chat’ during pair programming keeps all the parts of your brain engaged in solving the problem. Something that doesn’t happen so easily if you’re working alone, in silence.