Value of knowledge imbalance in pair programming

This article assumes that you have a basic understanding of agile methods and are some what familiar with the concept of pair programming.

Lets set the perspective straight first. Pair programming, or pair working rather, is not a new thing it has existed ever since the chimpanzees started doing “stuff” but as is the case with most things somebody formalised it, coined the term and the rest is history. You see it daily in your life. People trying to fix a vehicle on the road, friends trying to solve a problem in a class etc. These are of course examples of active pair working. There are numerous other forms. Most meta of which is the fact that almost all profound discoveries or innovations in our times are, in fact, based on incremental research. It is pair working taking place across time. Pair programming is just another specialised form of pair working.

Pair programming can, indeed, be a fairly valuable exercise if majority of the developers in a team adopt it. However, it helps to know the dosage of any good medicine, otherwise it can turn out to be distressful if not lethal. Continuing the analogy consider this article to be advice and not prescription. It can be fairly tricky to know when and where to use pair programming and that in itself can be a skill. However, if it is used effectively and non-religiously it can be highly effective. Generally, pair programming involves a team mate typing code and another driving the thought process. This is not to say that, that the coder is fully relieved of all thinking responsibilities or that the roles won't switch around. Also, there are plenty of pit stops for discourse.

Knowledge imbalance refers to the idea that different people in the team do not have the same level of knowledge. This does not mean that the people are any less skilled. It could just mean that people have different domains of interest. In a hypothetical code base of 2 classes and a team of 2 developers, one developer could be an expert of class A and another of class B, for example. Some managers or bosses, back in the day, used to be extremely uneasy with this idea because they expected everyone to know everything but I’ll save that rant for some other day. I think these days, people are becoming much more realistic and understand the value of domain expertise. They understand that in a software team people serve the roles of a medic, engineer, assault and a heavy gunner. It is up to the leader to know when and how to use these resources effectively.

I think pair programming is most effective in the following scenarios.

Induction

Pair programming can be extremely helpful when a new person joins the team. For a new team member, spending the first couple of days/weeks can be effective to iron out the learning curve.

Defect Hunt

When looking for the elusive bug that has been delaying that critical release, it is useful to pair up people. There happens, we theorise  and hypothesise like there is no tomorrow. It always helps to have some one around to play the devil’s advocate or provide a different take on the issue at hand. This could generally be applied to all difficult problems.

Knowledge dissipation

Pairing can be extremely useful to scatter and sprinkle knowledge evenly across your team. It is probably a good idea to create opportunity for other team members to gain access to some specialised knowledge.

There can be other more specific situations, as the ones described above. If one looks at the scenarios above it is clear in these cases the imbalance in knowledge/expertise plays a non-trivial role. This means that one peer will tend to be much more informed about the situation or problem at hand. Only in the case of a defect hunt i.e: a defect that is currently being diagnosed and has not yet been tracked down, the knowledge imbalance may exist but would only serve the purpose of having people bring in different points of view to the table or presenting different approaches.

I believe that to draw out the maximum value from pair programming we need to ensure that there exists knowledge imbalance in some form or the other. It is debatable however, how much the gap in knowledge should be, but that is an entirely different write-up on its own.