Optimal pairing

What was all that rambling about Harmonic Mean?

A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.

In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.

Pair with people of similar skill and experience

Maximum performance per pair is achieved when the pairs have identical skills and experience. This is, of course, highly unlikely. It is, however, fairly easy to put together a team with similar skills and experience. This provides us an opportunity to mix pairs, keep things fresh, and disseminate knowledge and experience more rapidly through the team without concern over the impact of mis-matched pairs.

When putting a team together, it is best to make sure the skill sets are within a few degrees of one another. When this is not possible, work to achieve a fairly even distribution of skill and experience. Avoid large gaps and do your best not to leave anyone isolated at the ends of the scale.

Exceptions to the "rule"?

The Software Craftsmanship movement encourages us to apprentice people new to software development. To bring them in, take them under our wing, and provide them the opportunity to learn through direct interaction with other developers in a structured and meaningful way.

Surely, Doc, you are not suggesting that apprentices should teach one another.

Yes, I am.

First of all, a good apprentice program does not immediately toss the new hire into a high-demand deliverable project. A good program provides the apprentice an environment where they can work on breakable toys designed to help learn fundamental concepts. Each step is a building block to the next, wherein fundamentals in both theory and practice are learned and built upon.

Under these conditions, who better to pair with than another individual of similar skill and experience? You can discuss, debate, discover, and learn all under the watchful eye and guiding hand of a more experienced journeyman or craftsman. The master cannot and should not devote his entire time to the growth of the apprentice. It is optimal, even as someone brand new to the craft, to pair with another much like yourself.


  1. I'm gonna have to go ahead and disagree with you somewhat, there, Doc.

    My first point is that "optimal" isn't always optimal. When a system approaches 100% utilization, the risk of breakdown increases as ordinarily insignificant pressure fluxuations propogate backwards in the pipeline, setting up an adverse harmonic in the 29th plane of existance (which we commonly know as the color teal-fuscha plaid). Nobody wants that.

    In short, the sub-optimal impediments of disparately-skilled programmers pairing offer to the veteran a much needed respite from the intense pressure of constant awesomeness. To the accolyte the mix-up offers a walk on the wild side, a chance to get a good look at what is possible, to stretch the mind, to grow his dreams.

    My second point is that measuring who is apprentice, who is yeoman and who is master is far from a simple, cut-and-dried matter. How shall we define the novice? "Fresh out of college?" We all know folks who rocked at software before they went into college, and dropped out because it was all so sub-optimal. Shall we say that the novice is new to this language or that? Or inexperienced at this practice or another? Which language(s) and which practices?

    Apprenticeship is a term which works only in the presence of a well-defined set of practices, which in the case of software developers, we have not even barely got.

    All this is *not* to say that diversity pairing is vastly superior to parity pairing. They are two different arrangements, and each of them has their virtues. I submit that they compliment each other, and that the successful venture makes room for both at various times.

  2. Joel:

    Thank you very much for the comment. And 'tis but a slight disagreement you make.

    This is my recommendation - "When putting a team together, it is best to make sure the skill sets are within a few degrees of one another. When this is not possible, work to achieve a fairly even distribution of skill and experience. Avoid large gaps and do your best not to leave anyone isolated at the ends of the scale."

    This is not easy to do. It is not easy to ascertain the competence of the team members, nor is it safe to assume their capacity for learning is equivalent. As a result, what is "optimal" needs to be frequently reconsidered.

    I do not, however, agree with your statement on apprenticeship. I believe we do have several well-defined practices that have proven to be very effective; SOLID principles and empirical approaches to mention only a couple. And apprenticeship is about providing individuals an environment and opportunity to learn and grow, not to be instructed. The apprentice learns from their own experience by your guidance. The industry as a whole need not have a formal tome of practices in order for apprenticeship to be successful. In fact, it is only when such formality exists that our "modern" education system seems to work. So I posit that until such time, apprenticeship is the only effective means.