A Gemini Dilemma

28 July 2014

Well, to get things rolling here I figured I’d start by talking a smidge about my most mature side-project - Coupling.

A few years ago I was working for a company that was very invested in paired-programming. During my time there, I noticed that careful massaging of pair composition (managers constantly choosing who is allowed to work with each other) was negatively affecting some team members - individual programmers could go for months without working together before it was noticed and corrected. I also observed that the process of carefully picking pairs each week was self-reinforcing - it appeared that it had to be done carefully because it had always been done that way. And finally, I observed that the reasoning behind specific pairing choices was obscured from the rest of the team - team members were frequently not aware of how the management team was assessing them and making decisions.

Here are a few additional notes of my own. As I see it, the principal purpose of paired-programming is to build a highly flexible and adaptable team - not to create a superior product, and not to avoid defects (though it shouldn’t be noticibly averse to these outcomes). Pairing’s best value-add is improving the quality of your developers by having them cross-train and teach each other constantly. One way this translates is unspoken disagreements and cultural discontinuities can be detected and dealt with much earlier over the course of a team’s work. This could be anything from disagreements about what ‘readable’ code means to deep opposing viewpoints regarding the correct course for an application’s architecture.

To summarize, paired-programming is a tool to help developers build better relationships with one another and improve each other’s skills.

Given all of that info, I believe that an automatically well-mixed pairing structure (rather then a managed or free-for-all structure) would still provide all of the benefits of pairing, with one additional advantage - removing the human element. I believe this has many benefits of its own:

• Alterations to pairing assignments would be public and justified
• The ‘last-one-picked’ stigma is no more!
• Pairing stops being associated with specific people or roles - anyone on the team can ‘Spin’ the wheel and your pairs are automatically made.
• The role of ego in assignments is reduced substantially; people can start working together with fewer barriers.

Alright, the list is slightly redundant, but you get the idea. At its root, the idea is to make pair assignments as simple and well-understood as possible in the name of transparency. More transparency, means more trust, means stronger teams top to bottom. And isn’t that what pairing is intended to help with anyway?

Why can’t everything be that simple? :-)

So that’s a little insight into why Coupling exists… though maybe it doesn’t really answer the question as to what it is. ;-) For that, check out the readme on the github page. And if you’re like to check out the program itself, voila!