Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 520 posts at DZone. You can read more from them at their website. View Full User Profile

Pair Programming: The disadvantages of 100% pairing

09.14.2011
| 7901 views |
  • submit to reddit

I’ve written a lot of blog posts in the past about pair programming and the advantages that I’ve seen from using this technique but lately I find myself increasingly frustrated at the need to pair 100% of the time which happens on most teams I work on.

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.

 

From http://www.markhneedham.com/blog/2011/09/06/pair-programming-the-disadvantages-of-100-pairing/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Tom Howlett replied on Thu, 2011/09/15 - 6:30am

I take your point that pairing 100% of the time isn't ideal and its good to have a bit of time to experiment, but I also think the developers who benefit the least from pairing are the ones that other developers benefit the most from pairing with. Meaning those really smart developers who are probably doing things in code that others wouldn't think of (and are capable of doing it on there own) need to share that insight with the rest of the team if the whole team is to stay comfortable with the codebase, and this is best done through pairing. If we are doing mundane tasks that can't be automated we'll often split but keep chatting (we usually pair remotely) so that we can quickly raise queries and keep focused.

Slava Imeshev replied on Mon, 2011/09/19 - 8:54pm

In my opinion, founding fathers of XP added pair programming to XP just to give it 'extreme' flavor :-) I bet they couldn't forsee that people will actually try it at home :-)

I prefer 'pair programming on demand' where anyone can just go and grab a colleague to work together on a problem that one feels stuck at. Practice shows that such pair programming sessions don't last longer than hour, usually less than that. After one got 'unstuck' the pair breaks up and everyone returns to taking care of their own business.

The only requirement for this practice is for team to know that everyone has a right to ask for a [short-term] pair.

Regards,

Slava Imeshev

Cacheonix | Clustered Java Cache

Milos Silhanek replied on Wed, 2011/09/21 - 4:23pm

Hi, one principle of XP is : take only what works. It is clever use the golden middle way (from Czech language). 100 % pair programming is not effective. When you go to trip you use little car or the bus for a group. WHen you want to bring bricks or sand you use a truck. Pair programming is useful - cases described by the article - the analyst knows what and the programmer knows how. Then the cooperation is a synergy. - when you need any dr. Watson to explain your problem.

John David replied on Wed, 2011/12/28 - 10:37am

Maybe your definition of pairing (or the definition of whoever is running your project) is a title bit too constrained. I always saw pairing as two people woking on the same problem, mostly sitting side by side on one machine but splitting to work on different strands when the pair sees fit. One of the biggest indicators of a successful team for me is when the team itself empowered to decide how to do the work themselves. A pair having a choice of how to do this should be a large part of that and so they should be able to decide how much is pure pairing, how much is side by side and how much is plain just splitting the work in half and getting on with it. The problem I often found, especially when you are a team of consultants mixed with client people, is that you can get insecure consultant team leads/tech leads who feel they have to control every aspect of the work and so dictate to the team exactly how things must be done and removing the freedom for the team to work out the best way itself.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.