Why I’m not a fan of pair programming

Pair programming feels like a lingering ghost. Its adherents proclaim it to be the best approach to coding while the rest of us just continue to ignore it. I’ve only tried it a few times. Based on those few experiences, and what I read, I’m not interested in trying it again. I’m a huge fan of collaboration, mentoring, and code review, but this idea of sustained pairing just isn’t appealing to me. Let me attempt to figure out why.

If you regularly do pair programming, please share how your experience contrasts to my opinions here. I’d like to see what I’m missing or misunderstood.

Dichotomy of experience

cup-985957_640One of the tenets of pair programming is that both members must be equally contributing to the process. If this is not the case, then you end up with more of a mentoring situation. I love mentoring, but it’s not the same.

Gaps in experience are expected in a job. I’m not just talking about “raw skill”, I mean everything from one’s familiarity with the code, to their understanding of the business, to their background in the field. Given any activity, it’s inevitable that one individual is more suited to the purpose than the other.

With a significant gap, I don’t see how a pairing won’t just become mentoring. While it’s great that knowledge will be shared, I’m uncertain how we could prevent a significant productivity drop of the dominant partner.

If I understood correctly, this gap is precisely one of the things pair programming is meant to address. It’s supposed to narrow the gap. I can see this happening for a new project member, at least for the first month, but I don’t believe the total experience gap will ever narrow — it would imply the senior partner is remaining stagnant.

Serialized thoughts

mind-2567460_640Shared experiences require the individuals to think in a similar linear style. To be open to feedback it’s important that my mind focuses on the code I’m writing. If I’m thinking anything, it’s important that I speak it out loud, letting my partner share in my thoughts. My outward actions must clearly map to my inner processes.

The problem is that I don’t work that way. The code I write is fragments of a total vision I have in my head. I’ll come and go from various source files piecing together that vision. It’d likely appear chaotic at times. If you were to interrupt my stream and ask out the bits, you’d throw me off-track, and it might take me a while to collect my thoughts and explain.

Of course, I can explain the code I’ve written; it’s important to be able to do this. The problem is the online requirement of sharing this knowledge. Pair programming is forcing me to serialize my thought process, which is a significant hindrance.

Continual sharing is also a load on the brain. Progress is massively hampered whenever the problem is too much for me to both analyse and speak at the same time. I’ll admit this isn’t true of most of our work, but these problems do come up.

Isn’t it pair “coding”

Programming is about a lot more than just coding, refer to my article I’m proud to be a programmer. Yet in all descriptions I’ve seen, pair “programming” is really about producing code. Maybe it should be called pair “coding”. The terminology itself isn’t my concern; I’m wondering how it fits into the bigger picture.

I don’t see coding as a distinct phase of the programming process. There’s a continual flow between writing code, analyzing requirements, talking to other team members, writing a fix on another branch, doing research, posting to online forums, eating a thoughtful sandwich, then eventually coming back to the original code.

I’m suspicious of any process that allows individuals to allocate large chunks of uninterrupted time to pure coding. Something seems off. Were the requirements so clear as to not need more feedback? Was the individual’s background such a perfect fit that they don’t need to do any research? Pair programming is supposed to stave off such isolation, yet appears to require it at the same time.

Tooling and remote work

remote-control-151856_640To a programmer that’s optimized their environment, it can be a shock to work with somebody else’s environment. Many minor changes, like colour selection, keyboard positioning, screen height, font selection, and more, alter my productivity. I can eventually adjust, but every time I switch results in a productivity drop. I experience this whenever I need to work on either of my laptops, when I do a live stream for coding, or when I connect to a remote system.

Remote is also a problem. There are a lot of benefits to being out of the office, either one day a week, or as a permanent remote worker. I don’t see how pair programming, as envisioned, can work in this situation. The tooling I’ve seen isn’t sufficient to support it. Both parties would be subject to a foreign environment, with an accompanying productivity drop.

Why not work together?

Perhaps my biggest critique of pair programming is this overriding need to work as a single enlightened individual rather than as two members of a team. Why can’t both people be coding at the same time? Why can’t one be writing tests and the other functional code? Why can’t one be doing some research and the other tracking down a defect?

I’ve had good experiences with two people focused on a problem, but both working at it from different directions. There’s a continual sharing of ideas, reviewing code, and asking for assistance. The team relationship is fluid and doesn’t require anybody give up their tools. It also doesn’t matter if there’s an experience gap — it’s okay if they’re working at different speeds, and the junior member has access to mentor as needed. Why can’t this be pair programming?

11 replies »

    • Why do companies push it as their primary approach to development? It’s kind of strange when the job listing itself indicates that everyone will be doing it and that it’s been determined to be the “best” way to code.

  1. I like pairing once in a while – if there’s a particularly tricky or large problem to sort out, it can be helpful to have the different perspectives, and 2 sets of eyes on the code being written to catch brain-farts before they have a chance to slow you down. 2 People can poke around in the codebase, talking out a plan for how to implement a feature, taking all sorts of different things into account – this is where a second perspective can help with bringing up those different considerations early on. While one person types, the other can partly watch what’s being typed, but also have enough distance from the code to still be thinking and seeing from a wider viewpoint. When you’re in the backseat, you may see some of the tricks the other person uses to optimize their work – you might want to try some of those tricks, yourself. I wouldn’t want to pair all the time, by any means, but I do think it’s a good practice now and then.

    • I have nothing against this type of occassional work, doing it quite often myself. But it doesn’t sound like it’s capturing the essence of what pair programming is meant to be, at least as pair programming is described. It just sounds like somebody helping you out sometimes, in a rather informal and unstructured fashion.

  2. Great post, thank you for the time you spend writing it, as well as all others. I’m slowly diving from one to another.
    I did experience pairing programming a few times. In the office, it’s kind of unproductive, it’s just “mentoring” but with extra steps.
    On the other hand, one time I particulate in a hackathon that was based on fast dating model. You and your partner have 15 minutes to find a solution to a problem. After 15 minutes partners and problem changes. That cycle repeats a few times, and by each time you find a new connection as well as have lots of fun :)

    P.S. Link to “I’m proud to be a programmer” needs a small bug-fixing :)

    • That sounds like an interesting hackathon. I do like activities that form stronger team bonds, but I’m not actually sure that “pair programming” is the best way to do it. That hackathon approach sounds better.

      Seems like I could have used a pairing for the article writing. ;)

  3. I have pardnered with other programmers from time to time. This works out when we have different experances. The relationship is simular to mentering. But I would not call it mentering when the pardner is of equal coding skill. Just of different experance. This was reciprocated in the code I wrote We worked together. These were mostly assembly coding. He was experanced on the processor while I had more overall assembly experience I had no experance on the processor we were coding. I had DEC-10/ TOPS-10 internals experance. Together we wrote a real time operatoring system that set on top of MSDOS.

    I pardnered with an engineer. Designing the computer board used in a factory floor data collection system that would run a version of the operating that system. I debugged board design. All problems were trace crossovers. Also with my pardner programmer we wrote a minimalist DOS so that terminal applications could be written in high leven languages.

  4. The only promoters of “pair programming” that I’ve met were incompetent programmers. Who needed someone to cover for their incompetency. Why would “pair programming” be useful in any way?

    If the answer is…well, “divide & conquer” then why not try “group programming”? And if that turns out to be limited by, well, space…if nothing else, then let each member of this “group” use their own space and then merge their efforts. Which…is pretty much how a software company works, via any source control tool (SVN, Git, etc.). We just call it a “normal day in the office” rather than “group / pair programming”.

    If the answer is, “because one programmer can catch the other one’s mistakes” then , well, we have automated tools for catching errors that are better suited for this kind of tasks than humans: compilers, profilers, debuggers, memcheckers, etc. (“…we should not force a programmer to do what the compiler can do better.” – Bjarne Stroustrup). If it’s about design then: (a) design can be discussed in group meetings in front of a whiteboard; (b) there are tools like UML diagram generators and code analyzers that can help clean up the design.

    If the answer is “because we bounce ideas of each other” then, again, bouncing ideas at the code-writing level might work if the pair is made up of two programmers with very different levels of expertise and the coding itself requires those diverse levels of expertise. If that’s the case, then, again, split the design into two (or more) separate moving parts, each requiring its own set of technologies and have the corresponding programmer design each of them. In separation.

  5. I have had several years of pair programming experience. I do think it can be a useful technique, especially early on as the design and architecture on a project are taking shape.

    – Shared understanding/resiliency: When individual developers take primary ownership of an area of the code, knowledge silos can form. When the person in charge of that code leaves, it can be difficult for someone else to take over. Pair programming, combined with regular swapping of pairs, gives the team a better over all understanding of the whole system.

    – Code quality: With pairing, I believe the system tends to converge more rapidly toward a so-called ubiquitous language. That is, the way the code works tends to be predictable and consistent across the entire code base. This applies to simple things like naming conventions, syntax, and testing, but I would say that it is deeper than that, affecting the algorithms used and the over all design. Of course one can try to achieve this kind of consistency in other ways – meetings, documents, code reviews – but I think working together live is a more efficient approach.

    – Design: The idea of pairing is very much for the members of the pair to do the design together. Whether it’s at a white board, a conversation over coffee, or separating for a while to figure things out individually and then coming back to finish the discussion later. I don’t think it’s just about coding as you allude to in your article.

    – Productivity: With pairing the idea is to bring the team as a whole to a more balanced state. Say you have 10 programmers. 7 of them are ‘good’ and 3 of them are ‘great’. Pairing the great programmers with the good ones may impede the great programmers’ productivity to some extent. However, if there is some percentage increase in the productivity/competence of the good programmers over time, it may be worth it. Plus the latter will hopefully have a better understanding of the system and will be able to support it without relying as much on the great programmers. I’m not saying this is a no-brainer, but it’s something to consider.

    – Team building: Programming is an area where people often hold strong opinions, sometimes about fairly small or academic matters. I think forcing people to work together early on will help to iron things out right from the start. The idea is to build up a level of mutual respect and for people to collaborate and compromise in the design of the system. Of course disagreements will occur, but it may be better to deal with these problems straight away and out in the open than to have them festering in isolation within the system (“Sunlight is said to be the best of disinfectants”).

    – Focus: I find that programming all day can get stressful and tiring. Over time, one can burn out and grow demoralized. To some extent pairing may mitigate this. Being able to spend half the time or so as a copilot, you can relax a bit while still being helpful, say by pointing out an idea for how to do something or spotting a problem early. You’re also still involved in understanding the code that is being written.

    All this being said, pair programming is not a panacea:

    – Ergonomics: I agree with the problems you’ve brought up concerning ergonomics. I think it’s something that has to be considered. I have found that it’s easy to get lazy about adjusting shared computers when switching, leading to less than ideal ergonomics.

    – Remote pairing: Pairing remotely is definitely harder than doing it in person. One can always use various tools, but I think it’s just a fact of life that pairing is unlikely to be as effective over a network connection as it is when people can easily talk face to face.

    – Personal style: The way you do programming makes me think of a jazz musician improvising wildly. It’s a very artistic way of doing things. Since it’s important for your pair to understand what you’re doing, I think pairing is likely to inherently cramp your style. I’m much more of a systematic and deliberate thinker. I break things up very much as you discuss into small, sequential chunks. I think for me pair programming is easier than it would be for you. Would it still be worth it for you? I think the answer is just “it depends.”

    – Burnout: After doing a lot of pair programming for several years continuously, I started to experience burnout from it. I wanted to have my own space and my own computer to quietly focus on my work. I think there is a balance to be found. That is, not pairing at all may be a bad idea, but pairing all the time is not necessarily the way to go either.

    My conclusion is simply to say that I think pairing is a reasonable thing for a team to have in its toolbox. It should not be applied in a dogmatic way, and developers should have some flexibility around it.

    • Thanks for the detailed response. There are a lot of good points in there. It seems like when it works for people it can bring some advantages.

      Though I like how you mention fatique as both a problem with and without pair programming. Having alternate approaches can definitely break up the work schedule. I defintiely find pairing with somebody is more enjoyable near the end of the day when I’m running low on energy.

      Some of the arguments for pair programming, including those youv’e mentioned, seem to assume that without pair programming people will work in isolated silos. I think however that we’d agree such an approach to development is dangerous and prone to failure. If a team already has a healthy dynamic by sharing thoughs, having short design sessiosn, reviewing code, and mentoring there is no “ideal” to be obtained with pair programming. I would imagine such a team would regularly engage in things that look like pair programming without being formal or strict about it. It’s a tool that they would just use, as you indicate.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s