Effective vs Ineffective Pair Programming

Pair programming has always been one of the more controversial agile practices. Mostly because it is damn hard to sell to management (at least the unenlightened kind of management), we’ve all heard the old “double the cost for the same work” excuse. To those in-the-know that excuse is patent nonsense, those who’ve done it are well aware of the benefits that it brings even if they do sometimes find it hard to verbalise just exactly what those benefits are.  Pairing brings all sorts of benefits:

  • organic code review
  • less bugs, which means less maintenance effort
  • detecting problems early
  • more focused effort (harder to procrastinate when person next to you)
  • etc.

The most important benefit in my opinion is the fact that pairing is highly conducive to organic knowledge transfer (“pairing is knowledge sharing” for the poet in you). I believe this is key since in a large system there is literally no other way to do this well.

It is however interesting to ask exactly why pair programming brings those benefits and this would directly lead us to ask if there are any situations where pair programming can be less effective and what we can do to mitigate that.

What’s So Good About Pairing And Why It Works

The  reason I think pairing works so well is the fact that the “driver” and the “navigator” are mentally in completely different places. Andy Hunt explains this really well in his “Pragmatic Thinking & Learning – Refactor Your Wetware” book. The driver is focused on the nitty-gritty of the code, his mind is in its analytical mode (his left brain is more engaged) and he is more focused on the “small picture”. The navigator on the other is more focused on the bigger picture and due to the fact that he is not actually busy driving his mind is in its more intuitive mode (his right brain is more engaged). This means that the navigator is more able to see patterns and abstractions that the more analytically engaged driver will tend to miss.

However in order to be able to see the patterns and notice the abstractions, good system knowledge is invaluable (and the best way to gain it is through pairing so this is sort-of cyclical), which brings us to 4 situations where pairing can be either less or more effective.

The 4 Pairing Situations

The 4 situations are as follows:

  • the driver and the navigator both know the system/area well
  • the driver knows the system/area well, while the navigator does not
  • the navigator knows the system well while the driver does not
  • both the driver and the navigator do not know the system/area well

Driver and the navigator both know the system/area well

This is the ideal situation (obviously), and there is no need to say to much about this, when pairing having both people well versed in the system will ensure maximum effectiveness.

Driver knows the system/area well, while the navigator does not

This is a lot less ideal, in this case the person with the most knowledge of how the system works is in their analytical mode and is a lot less able to see the bigger picture and pick up on the appropriate patterns and abstractions. More than that, since as the driver they are focused on the task at hand and are actively busy/engaged they are potentially less able to share their expertise with their partner. The navigator is also extremely hampered by their lack of system knowledge, not only are they limited in their ability to help the driver, but they will also tend to feel frustrated and unfulfilled.

Navigator knows the system well while the driver does not

This situation is a lot better. In this case the person with less system knowledge is fully engaged as the driver, the navigator on the other hand is able to guide the pairing effort and is still able to see the code from a right-brain perspective. The navigator is also able to maintain a stream of commentary about the system for the driver to absorb. The downside here may be that the work proceeds somewhat slower due to the lack of system knowledge on the part of the driver. This can however be mitigated by discussion between the members of the pair before proceeding to do the next step in the work.

The driver and the navigator do not know the system/area well

From the perspective of getting some work done this is the worst situation to find yourself in. It can however be quite a lot of fun to dig through code you don’t know, as well as find and recover from mistakes together. The danger here is due to the fact that neither person is potentially able to appreciate the bigger picture –  the quality of the work can suffer and it can be inconsistent with the rest of the code in the system.

It is difficult to mitigate lack of system knowledge, there is always a significant amount of time and effort involved when the system is of reasonable size. I believe there are 2 ways to ensure that pairing brings benefit no matter what the situation:

  • the person with the most system knowledge should spend the majority of their time being the navigator rather than the driver, in this way they can bring the most benefit to the system as well as to their partner
  • both members of a pair need to ensure that they are constantly proactive both in learning and in teaching

Do you think there are other ways to make sure that our pairing efforts are always optimally successful? Feel free to leave a comment and let me know.

  • Pingback: LATEST UPDATED BLOG » Effective vs Ineffective Pair Programming()

  • John Turner
    • True, however – when you’ve been pair programming for a while you do start to notice that you’re in a different frame of mind when you drive compared to when you navigate. Call it right brain vs left brain or call it whatever you like, but there is no doubting that the dichotomy exists.

  • Pingback: Helltime for July 24 « I Built His Cage()

  • Petros Amiridis

    Well, you can call it “changing perspectives”.

    • That’s as good a description for it as any.

  • Pingback: Angel "Java" Lopez()

  • This is very interesting. I have never heard of the term “pair programming” before. In fact, searching google didn’t help either.

    From my understanding, basically this is all about working as efficiently and effectively as possible in a programming environment. My background is from a php production web shop, and trying to get everyone to be on the same page in working with a specific system or specification is a major pain in the butt.

    I have a hard time figuring out whether I am a driver or a navigator. I “think” I lean more towards being a navigator because it is all about being productive/profitable in my head and less about the specifics of the code.

    • Hi Chris,

      Everyone has a preference when it comes to pair programming, although most people prefer to be hands on at least some of the time. It is important to make sure you both drive and navigate at least sometimes. Both of these train and require somewhat different skills.

  • Pingback: How to Thrive in Pairs « Awkward Coder()

  • Thank you Alan! I was looking for an article that describes pair programming in the Refactoring your wetware perspective. Good read!

  • Josh Goodwin

    Recently I’ve been experimenting with a time or task related pair swapping cycle. We break down our tasks into smaller, manageable chunks of work and when that task is done, we switch driver for navigator and continue to the next task. With larger tasks we attempt to swap after an hour or so to avoid the ‘narrowing of view’ that comes from being in either role too long. It has worked out well, so far, for us. We’re currently focused heavily on developing new code, however, and this practice may be preferable for creation of new software rather than maintenance or alteration of existing code bases. But this idea may help to resolve issues with Alan’s fourth case (both people in the pair having a lack of system/area knowledge) allowing both people to spend equal time in both roles when one does not stand out as the ‘better’ choice for a role.

  • Great comparison of the 4 situations! 👍