Pair Programming in Perspective

Annual Mermaid Parade
Coney Island, 2012

I offered my 2¢ on this question from another developer:

Would you consider joining a company where pair programming is an essential part of software development?

One long-standing lesson from Extreme Programming is:

Programming in pairs improves quality. 

With qualifiers, few dispute this assertion.

Recently I've learned of mandates for pair programming which is mildly alarming. A team at BestBuy does pair programming ...all the time. This particular pair-programming-all-the-time initiative had the unintended consequence of chasing off one of the most test-driven, quality-focused craftsman I have pair programmed with, and learned from, in years past.

Let me state this:

Paired programming mandates are a bad idea.

Mandates in general are a bad idea. Producing software is a creative act. Mandates stifle and demoralize.

Pair programming is most helpful when on-boarding new team members, or when intentionally pairing an experienced developer with an inexperienced developer.

Software produced in pairs is typically superior, but not always the smoothest tack. Sometimes pairing is jarring to the soloist's creative flow. At times, pairing is downright inefficient.

It's common to achieve quality results on par with pairing by having peer reviews and team discussions. I'm an enthusiastic cheerleader for the Pull Request Workflow popular on GitHub and BitBucket (see Pull Requests for Teams). Pull Requests allow for collegial discussions that lead, more often than not, to quality improvements.

Mandates are a red-flag for team and organizational inflexibility. My answer to the developer's question "Would you consider joining a company where pair programming is an essential part of software development?" is a qualified no.

Two heads are usually better than one, but not always.

The development community has realized significant strides from XP and Agile, but shouldn't we be judicious about — and mindful of — how we apply what we've learned?

More ain't better, particularly when it's dictated over pragmatism or common sense.

Not every arrow in the quiver suits a situation.

REFERENCES

• Extreme Programming, Wikipedia.
• Paired Programming, Wikipedia.