From my experience it’s certainly useful as a coaching tool, as I’ve mentioned before I think it’s a very useful for increasing the amount of collaboration between team members and an excellent way for ensuring that knowledge of the code base is spread across the team.
On the other hand I no longer see it as the silver bullet which I did previously and I think we do lose some useful things if people get forced to pair all the time.
Time to explore the code
Mark Wilden wrote a blog post about 18 months ago where he pointed out the following:Pair programming doesn’t encourage quiet reflection and exploration. You can’t just sit back and read some code. You can’t just sit and think. I mean, you can, but then your pair is just sitting there.On the project I’m working on at the moment we pair on everything so if you want to spend some time scanning through the code and seeing if there’s ways to improve it then you tend to end up doing that in your own time.
If I start to explore the code or do some scratch refactoring, while pairing, to see how the code would look if we structure it slightly differently then unless my pair is interested in what I’m doing then more often than not they’ll start playing with their phone.
The alternative is to try and explain exactly what you’re trying to do but more often than not you’re not entirely sure or it takes longer to explain than to try it out.
I think we can easily create this time for people in the day by just agreeing to pair maybe for 7 1/2 hours in a day instead of 8 hours.
In the name of (short term) productivity
When you’re working as a pair one of the things that it’s supposed to improve is the productivity of both people – it’s much easier to get distracted by something or go down a rabbit hole when you’re on your own than if you’re pairing.
On the other hand I’ve started to wonder whether what we’re actually achieving is short term productivity.
In my experience house cleaning tasks such as investigating why a test is ‘randomly’ failing on the CI machine are less likely to be looked at if everyone on the team is pairing 100% of the time because it interferes with productivity of a story.
There is some logic to that because investigating things like that can lead you down a rabbit hole but not addressing them isn’t particularly helpful either since they’re bound to ‘randomly’ fail again in the future and cause pain.
I think pairing can also be detrimental to learning how to use new tools although I can certainly understand the argument that you should be learning things like that in your own time anyway.
For example I know a little bit of Sed and Awk and there are often times when we need to do text replacement across a series of files and it’s very boring for my pair to watch while I try and work out exactly how to do that.
More often than not we end up doing that task manually which is slower but less frustrating for the other person.
Diminishing returns
I think pairing works very well when there’s a new problem to solve and there’s some thinking to be done around how to design code but it tends to diminish once we’ve built the cookie cutter.
A reasonable amount of the work required to develop a standard web application is quite mundane once you’ve worked out how to do it any subsequent work in that area tends to be about following the established pattern.
It might not be the best pattern but in my experience it’s less likely that you’ll go against the pattern if you’re pairing since you’ll have your ‘productivity’ hat on.
There is an argument that if you’re pairing and it’s boring then you should find a way to automate that problem or make it possible to write less code.
There have been times when I’ve seen pairs do this but I’d say in a lot of cases there isn’t a significantly better way to solve the problem.
Jay Fields recently written a post about his experiences after pair programming and while I don’t think the types of projects I’ve worked on are ready for his approach I don’t think 100% pairing is the answer either.
Source : http://www.javacodegeeks.com/2012/01/pair-programming-disadvantages-of-100.html
