Summary
You’ve tried pair programming for a bit and it just doesn’t seem right for you. The whole concept of extreme programming is appealing to you, but you’re having trouble with the pairing part. Don’t worry – you’re not alone.

You’ve tried pair programming for a bit and it just doesn’t seem right for you. Maybe it’s the people you’ve paired with or maybe it’s the whole idea. The whole concept of extreme programming is appealing to you, but you’re having trouble with the pairing part. Don’t worry – you’re not alone. Some of the original signers of the Agile Manifesto don’t pair program. It’s not for everyone.

There are many reasons why pair programming may not feel right. Many programmers are introverted in terms of their thought processes. Introverts tend to think internally before coming up with an answer. The extrovert is the opposite. They try to think things out verbally. One way of describing the difference is that introverts “think, talk, think” and extroverts “talk, think, talk”. So you may have different thought processes than your pairing partners. Though opposites may work in love, they have a harder time working at work.

Another reason may be pace. You may like to do things at different speeds than your partner. Watching another programmer hunt and peck his way on a keyboard can be frustrating. One common facet of pair programming/extreme programming is running the tests every few minutes – keeping the progress bar all green. That may seem like MTV land, when you’re more used to classical music. You may like to make several changes before running the tests, as you may have some experience in which changes need immediate testing and which changes don’t interact with other changes.

Still another reason may be style. You may like to write code in a sloppy manner and then let a code beautifier clean it up once you are done. Your partner may be a stickler for pure indentation.

The important thing to understand is the principle behind pair programming – two sets of eyes looking at code. Two sets of eyes catches errors that may show up later in full testing. A second set of eyes can tell how readable is your code.

The implementation of this principle – concurrent looking – may not fit into your personal preferences for the reasons given above. There are many ways of implementing this principle. You can have pre-programming pairing where you discuss with another developer the changes you’re going to make in the code. You can have post-programming pairing, in which you explain the changes you’ve made to another developer.

The important thing is to be flexible in what you’ve coded – be prepared to change your code. If another developer is having trouble understanding your code, then it may be too complicated. As your code is reviewed by more of your team members, you’ll be able to hone in on creating code that requires few if any changes.

If you are part of an agile team that wants everyone to pair program and you have problems with it, suggest some of these alternatives that meet the same goal. If they refuse to acknowledge alternatives, then they really aren’t being agile, are they?

Talk Back!

Have an opinion? Readers have already posted 4 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Ken Pugh adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Ken Pugh of Pugh-Killeen Associates (www.pughkilleen.com) consults, trains, and mentors on technology topics ranging from Object-Oriented Design to Linux/Unix to the system development process. He has served clients from London to Sydney. When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail.