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

Where art thou been?

(Disclaimer: you will find nothing of value in this post. Leave now.)

So, here's me, welcome to the party. For the life of me I cannot even begin to understand how it's taken me to until December 13, 2008 to actually create my own personal blog. It's an anomaly. Whacked. Crazy. Odd. Questionable.

Anyone who knows me knows that, more often than not, its hard to shut me up. I love to write, I've been doing it for many years, and in many ways, for many reasons. I've written much about many things. Much even about software, and about agile, about people and the world we all rock.

So where have I been? Who knows, maybe I was subconsciously afraid no one would give a flying crap what I had to say in the blogosphere and was avoiding the rejection? Maybe I wasn't properly motivating myself? Maybe I was too busy with other stuff? Maybe I'm just lazy (yes, that's it).

It's unfortunate, really, how much people fail to do the things they know they should do, or want to do. How much we let something get in the of way it. Personally speaking, and professionally. In life, and in business...and, here it comes, definitely in software development. People, all over the world, knowing they could or should be doing software better. Designing better. Coding better. Delivering better. Collaborating better. Communicating better. Trusting better. In the end - living better.

Doing it better...and having more fun doing it!

So, here then lies the root of what you'll likely find here: writings...well, ok, ramblings (some useless, some useful, some idiotic, some wise, some comical, some ridiculous, some stupid, some cool), that chronicle whatever might be striking my fancy any given sunny day about the world of software and the people who inhabit it. Sometimes it'll be geeky, sometimes business-y, sometimes touchy-feely, sometimes none of the above. We'll see.

Anyhoo, just needed to get that off my chest, that was for me, please do disregard this rambling collection of words. Promise, no more stream-of-consciousness psycho-babble about "me" (well, at least not for a little while!). From here on out, we talk of our craft. We talk of software, and of that funny thing they call "agile".

See ya soon.