Why do pears fall in love?

So, I've been following Corey Haines' Pair Programming Tour. Check it out, it's a rather cool gig, both as it brings the topic of Pairing back under a much needed limelight, as well as, in and of itself, the totally unique and inspiring act of Corey taking such a tour in the name of our craft. Kudos Corey!

It's got me re-inspired to write up some of the things I've always wanted to about pairing, as I'll do now and then here in my nifty new super fantastic blog.

To start, I'm drumming something up from one of my first writings years ago about this wonderful thing we call Pair Programming. It's a simple list, intended to highlight the major reasons why we pair. Here it is...

When programming (ie. designing) alone even the most disciplined/skilled of us will:

• Get stuck on various "how to's" (often for a great deal of time)
• Often stray, both in thought and code, away from the current task at hand
• Spend a lot of time debating various decisions in our head
• Create designs only we understand, thus requiring a future time-consuming learning curve for everyone else (trust me)
• Be prone to, at least occasionally, make bad decisions - each of which incurring technical debt*
• Be prone to make programming errors (especially if we're not test-driving), thus incurring technical debt*
• Be likely to "cheat" (out of good programming practices), thus incurring technical debt*
• Periodically get burnt out, requiring a break [during which time no work is done]
• Have no one to encourage us or celebrate with

* "technical debt" = exponentially costly [ie, time-consuming] future rework!
See also: Martin Fowler on Technical Debt

When pair programming (ie. designing) even the least disciplined/skilled of us will:


• Rarely get stuck on any "how to's" - for those things that stick us, our pair is highly unlikely to be stuck as well
• Remain focused on the task at hand
• Be able to more efficiently [quickly] make design decisions collaboratively with our partner
• Be sure that at least one person won't have a time consuming learning curve to understand my design
• Be forced to verbally justify the rational for our decisions, thus greatly decreasing the likelihood that we "miss something"
• Rarely make a programming error that our pair won't pick up
  
• Not be able to "cheat"
• Be able to pass the keyboard to our pair when we need a break - keeps us moving, and keeps us fresh
• Have someone to constantly encourage us and celebrate with (ie..fun)

For these reasons, it has been shown that diligent pair programming, at least over any non-trivial period of time, does not decrease team velocity. In fact, it will often increase team velocity (and, as a nifty side effect, software quality as well).

So, chew on that, maybe it'll help you in the next hallway conversation where you need to explain to someone how "pairing does NOT double the time it takes to get something done".

And of course, remember why this is necessary in the first place: The world we live in these days, well kids, It Ain't Your Daddy's Software Development...

**Update: Check out this for some Q&A about Pairing