Pair Programming Observations

[article]
  • read out-of-date manuals for a week, or worry that you're going to be fired because the system looks indecipherable.

These benefits come about from monitoring the process, making sure the technique is executed well, and fixing problems. Don't forget a coach!

Skill Level Gaps
An experienced developer can outperform an inexperienced developer by two, three, five, ten or even twenty times. Sitting with a novice can be excruciatingly painful. But I'd rather burn a little time bringing other guys up to speed as soon as possible. It pays off in spades.

Pairing allows me to keep tabs on their work and make sure they are not producing junk that will have to be rewritten. It also prevents them from holding up the project. Several years ago I was on a project that ultimately go cancelled, largely due to the schmuck that couldn't get his work don in time, and when it did get done, it was garbage. With a pair, incompetence that can destroy a project surfaces far more quickly.

I still learn some very interesting things from working with novice developers. And they learn a wealth of things that they would never learn were they to be left to their own devices.

Leaving an inexperienced developer alone to suffer through the system and other issues presents them with a steep learning curve. Through pairing, this learning curve begins to flatten more early on in the project. The more time I spend up front with a novice developer, the more we can depend upon their contributions later in the project--when it matters far more.

Of course, the novice must be capable of growing. Pairing lets you find out quickly who's worth keeping versus who will always be a drag on the team. Management can get involved in the first month or so of a project, as opposed to late in the project when it's crisis time.

Final Comments
I've been in the position of promoting XP and hence pairing as a consultant for a while now. Until I did a longer, six-month consulting stint, my pairing experience was more sporadic. Sure, I saw the benefits and the negatives, and did it enough to know how to make it work. Plus I learned plenty more about it from other sources. But until I sat there and actively paired for a longer duration, some of its nuances weren't as evident.

In fact, pairing seemed to me like a nice thing to promote, but maybe pairing wasn't something that I needed to worry so much about. Not drinking my own kool-aid!

What I realized is that pairing after a while becomes a dependency, in both a good way and a bad way. I learned to look forward to most pairing sessions (there are always some difficult people). I also felt naked when not pairing, and begin to question more what I produced by my lonesome self. Pairing became assuring and thus relaxing.

Before, I would be overly confident that I was a great programmer and that I produced code that was just fine. Maybe not! A few pairings with some sharp people and I learned a few cool new techniques. I took on more humility.

Dependencies in code can be bad, as can dependencies in life. The secret is in managing these dependencies well. Learn to use pairing as a tool to help you do better the next time you aren't.

Copyright ©: 2006, Jeff Langr. All rights reserved.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.