The reasons for pairing pair programming are well documented, and while I generally believe it to be a good way to develop software, I don’t believe in a one size fits all approach to anything.

One of the main arguments for pair programming is knowledge sharing. Frequently rotating people across different stories gives them broader exposure to the system than they may otherwise receive. This benefits the team as everyone becomes familiar with all aspects of the system and anyone can support any part of the system as needed. That’s the theory, anyway.

I’ve been thinking recently that we can achieve the same result providing we are able to consistently produce small stories or tasks which take no more than a couple of days to complete. This gives us the the benefits of rotation as individual developers are able to move on to new stories at a quick and consistent pace. Small, consistently sized stories also have the benefit of helping the team to achieve flow. By that, I mean features can be pulled through the development, testing and sign off process at a steady pace, and bottlenecks in this system are avoided.

Another argument for pair programming I’ve been considering is that it produces better design and makes tough problems easier to solve. After all, two minds are better than one, aren’t they?

While many developers may be able to solve the vast majority of problems they face, as they become more experienced they learn to recognise good solutions and bad ones, and everything in between. I think a mature developer should be disciplined enough to recognise when they don’t know the best solution to a particular problem without the need for pairing.

A less mature developer may go ahead and implement the bad solution, and get the job done albeit in a way that is likely to have longer term negative consequences for the project. A good developer will stop to informally run through their thought process with a colleague, or gather everyone around a whiteboard to discuss options. This again helps with knowledge sharing within the team.

While I think pairing is beneficial, I take a pragmatic approach to doing it. Sometimes a team can be more productive without pairing, and at other times paring can make a team more productive. I don’t believe that pairing needs to be used by all members of a team all the time. If a couple of people decide to pair, that doesn’t mean everyone else has to. Making rules like this can actually have a negative effect on the team.

It’s not that some developers are above pairing, while others need supervision. It’s about being able to identify the best approach to the task in hand, and being able to adapt as necessary.