Mark Needham

Thoughts on Software Development

Pair Programming: The disadvantages of 100% pairing

with 12 comments

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.

Be Sociable, Share!

Written by Mark Needham

September 6th, 2011 at 11:34 pm

Posted in Pair Programming

Tagged with

  • http://twitter.com/perrynfowler perrynfowler

    I don’t understand why you equate pairing with ‘having your productivity hat on’, or why you differentiate pairing time and ‘own time’ – as if time spent pairing did not belong to me somehow.

    When I pair, I see no reason why we wouldn’t spend some time together scanning through the code, learning new things or . It downright horrifies me that pairing is seen as something that makes people less likely to investigate a build failure.

    It sounds like the real problem is a reluctance in the team to invest time in anything other than direct ‘story delivery’. Setting aside some ‘non-pairing time’ where you can work on things that are not ‘story delivery’ is likely to make this worse, not better. 

  • http://twitter.com/markhneedham Mark Needham

    “It sounds like the real problem is a reluctance in the team to invest time in anything other than direct ‘story delivery’. Setting aside some ‘non-pairing time’ where you can work on things that are not ‘story delivery’ is likely to make this worse, not better.”

    Yeh you might be right about that actually – there’s a very big emphasis on the number of points completed each week which I think either subconsciously/consciously contributes to what I’ve described. 

    “It downright horrifies me that pairing is seen as something that makes people less likely to investigate a build failure.”

    That’s what I’ve been noticing anyway. Perhaps it’s linked to the reluctance that you mentioned above and people feel the reluctance more when they’re pairing than when they’re alone? 

  • http://www.brunton-spall.co.uk Michael Brunton-Spall

    “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.”
    But this is exactly the sort of thing that I want to do while pairing.I’m one of the Sed/Awk ‘experts’ here and if it stays that way then I end up doing all of the log parsing and performance work because I can get it done quicker and faster than people who’ve not used sed and awk before.  If I pair on this task I try to engage my pair in what I’m doing, explaining how sed works, why we are writing it like this and why I might use other tools like grep, cut, sort, uniq and so forth.  If my pair learns these tools they become a better developer overall.If you don’t know how to use a tool, then sometimes working with a pair can help you find out how the tool works more efficiently as you get the combined knowledge working on the problem.  Maybe your pair has used vim and so recognises the /regex/replacement syntax, but you’ve used more unix tools and understand pipes better.  Hopefully you can work together to solve the problem.  If when you approach a problem like this your pair gets bored and checks their phone you have a totally different issue than pairing.

  • dcabel

    I completely, 100% agree with the idea that pair programming has some major drawbacks. I was on a large team-large project for 3 years in a pair programming environment and not until the 3rd year was I let off on my own to investigate and poke around in the code. It was only then that I realized how some of that code in far reaching places really worked. I was never given the time to test on my own, my partner(s) were, for the most part, on the project from the beginning so they knew the code and the reasoning since its inception which took me far too long to achieve. 

  • http://www.markhneedham.com/blog Mark Needham

    @mibuk:disqus yeh that’s probably fair. I guess the way I see it is that I’m always really enthusiastic when I see the chance to use the unix tools to solve a problem and I often notice my pair becomes very detached when I do that so I tend to stop myself now. 

    I can definitely see that it’s a very useful way to learn the tool so perhaps I just need to become better at using it so I’ll know exactly how to use it when the chance arises and I can teach my colleagues.

  • Llewellyn Falco

    I pair in a different style, where we enforce the rule “to go from 1 persons head to the computer, it has to go though the other persons hands” this prevents the “bored playing with your cell phone” as communication is always maximized.

    But we also had the “need time for reflexion” issue. We solved this nicely with pomodoros. 25 minutes on, then a 5 minute walk around the block. this gave us time away from the computer to reflex and think of the bigger picture. of course we walked together, so I think it still counts as “pairing”  

  • Mark Wilden

    Naturally, I don’t have to say that I agree with you 100%, Mark. BTW, I wrote a companion piece that explored what I love about solo programming (http://mwilden.blogspot.com/2010/12/why-i-love-solo-programming-and-why-i.html).

    In my experience, pairing leads to a lowest-common-denominator effect. If both people are interested in delving into sed, then it will happen. If only one of them is, it won’t. Replace “sed” with any other technology, and the statement holds.

    One of the most important LCDs is productivity. Everyone wants that. So pairing teams (again, in my experience) tend to be very productive. They knock out stories fast. But if your main goal is racking up story points, then, no, you will not be as eager to refactor, to reflect, or to explore.

    I don’t see how allowing 5 minutes per half hour (or a half hour per eight hours) of “alone time” really solves this. I don’t want to schedule my time for reflection. Yet pairing (obviously) requires lots of scheduling. I never felt so evil for taking an extra half hour for lunch as when I came back to find my pair balefully waiting for me. And I absolutely hate having to set the alarm clock at night.

    On the other hand, many of the people I highly respect love pair programming. There are unquestionable advantages that weigh against the disadvantages. But those disadvantages still exist, and for me, bulk larger. Would I take another job that had pair-programming? Yes – but only if pairing was the exception, and that I could spend most of my time in my own personal flow.

  • http://www.markhneedham.com/blog Mark Needham

    @google-48641c4be1fbe167929fb16c9fd94990:disqus edited the comment to fix the link to your solo programming post which wordpress screwed up!

    That’s an interesting observation about the lowest common denominator effect which I’ve noticed as well. 

    I’ve certainly paired with people where we were both enthusiastic about exploring a bit of code/tool and then it’s been awesome because we end up with a better result than we would have done alone.

    I think it’s a trade off between what works for different people but I’m always wary when something is proposed as a solution to every possible situation/context which sometimes it feels like pairing is.

  • Mike Wagg

    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.

  • http://www.markhneedham.com/blog Mark Needham

    Nice observation – I hadn’t thought of the idea of splitting up during pair if it made sense. I think that makes sense  and probably works better as a rule than working solo and then trying to find someone to pair with when you need to.

  • http://derekneighbors.com Derek Neighbors

    I like the challenging of norms.  I think the reflection bit is bunk only because it implies that the team isn’t looking and reflecting outside of the normal work day.  This seems odd to me.  Some of it goes back to delivering business value.  At some point the team has to be willing to invest in itself as much as the business does.  I think Mike Wagg’s comment about pairs tackling problems is valid as well.  Ultimately, a good team is extended the ability to do work how they see fit.  If they don’t see pairing 100% of the time as being most efficient for them.  I always am leery about anyone pushing absolutes.

  • Curtis Cooley

    Does anyone actually write code 8 hours a day? What about the 5-15 minute standup, short design session, gasp – meetings?

    When I pair and want to reflect on code I ask my pair the questions I want to ask the code. Often she has the answer. When she does not have the answer, at least I’ve formulated and fomalized the questions I want answered so I don’t end up casually browsing the code while she sits wondering what I’m doing. When I want to experiment on the code, I tell my pair what I want to try. Sometimes she’s already tried that and it didn’t work out. Sometimes she improves on my plan and we try that. Sometimes she says, “oh, I never thought of that, let’s do it.” Rarely it breaks down into an argument on how good the idea is instead of just trying it.

    Like Garald Weinberg said, “It’s never a technical problem, it’s always a people problem.” Issues with pair programming are not technical problems, often they are communication problems. Not to stereotype us, but we tend to not be good interpersonal communicators which is what makes pair programming exhausting.