Pair programming is not a new concept. It’s been around for at least for a couple of decades. Distributed, virtual, or remote development teams also aren’t a novel idea. And combining the two – remote pair programming – is not a new construct. Yet I’m wondering why we don’t do more of it.
Advantages & Outcomes of Pair Programming
The wins from pairing are well documented:
- Collaboration in real time
- Team-building
- Faster learning (for both mentor and mentee)
- Quality: Better design & code / fewer defects
- Less lotto factor (aka bus factor)
- Higher team productivity
- Increased team morale
Why aren't we doing more remote pair programming? Click To Tweet
Some Variables to Play With
The possible constructs of pairing allow for incredible variation:
- Assorted paring variations (see below)
- Assorted sized “tickets” S, M, L, etc
- Asssorted complexity (hard problems/simple problems)
- Assorted time frames for pair lifetime (clock time, story boundary, iteration boundary)
- Communication channels – audio, video
Pairing Variations
(https://en.wikipedia.org/wiki/Pair_programming)
Expert–Expert
Expert–expert pairing may seem to be the obvious choice for the highest productivity and can produce great results, but it often yields little insight into new ways to solve problems, as both parties are unlikely to question established practices.
Expert–Novice
Expert–novice pairing creates many opportunities for the expert to mentor the novice. This pairing can also introduce new ideas, as the novice is more likely to question established practices. The expert, now required to explain established practices, is also more likely to question them. However, in this pairing, an intimidated novice may passively “watch the master” and hesitate to participate meaningfully. Worse still, the Expert may simply withdraw their labor and get employment elsewhere.
Novice–Novice
Novice–Novice pairing can produce results significantly better than two novices working independently, although, this practice is generally discouraged.
Remote Pair Programming Tools
The available tools for remote / distributed teams removes just about any possible barrier to making pairing work.
Here’s a short list… (And I’m sure there’s plenty of others… please comment below with what you’ve tried)
- motepair: “an Atom package for remote pair programming”
- screenhero: “tailored for effortless real-time collaboration” – with a really nice Slack integration!!!
- Google Hangouts w a screen share… (so last year…)
Why Not Get Started?
If you’re currently doing no pairing, why not start simple? Try a pomodoro or two.
See what happens, and share what you’ve learned.
Reference Materials / Read More
- Practical Styles of Pair Programming
- https://www.thoughtworks.com/insights/blog/10-ways-improve-your-pairing-experience
- http://www.devx.com/enterprise/seven-secrets-of-successful-pair-programming.html
- https://en.wikipedia.org/wiki/Pair_programming
- http://www.solutionsiq.com/a-hard-dev-lesson-whose-time-has-come-your-first-attempt-is-rarely-your-best-attempt/
- http://www.gargoylesoftware.com/practices/pairprogramming
- Pair Programming Illuminated (2002)
- Improvement Dialogues & CoPilot Programs: How to go from simple coaching to cross-functional change management