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.