Summary
Youve tried pair programming for a bit and it just doesnt seem right for you. The whole concept of extreme programming is appealing to you, but youre having trouble with the pairing part. Dont worry youre not alone.
Advertisement
Youve tried pair programming for a bit and it just doesnt seem right for you. Maybe its the people youve paired with or maybe its the whole idea. The whole concept of extreme programming is appealing to you, but youre having trouble with the pairing part. Dont worry youre not alone. Some of the original signers of the Agile Manifesto dont pair program. Its 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 youre 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 dont 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 youre going to make in the code. You can have post-programming pairing, in which you explain the changes youve made to another developer.
The important thing is to be flexible in what youve 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, youll 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 arent being agile, are they?
I am certainly one who does not "get it". Ken really has only touched the surface here. I'd put sanitary concerns at the top of my list. My lab experience involved colds being passed from one developer to the other. You could almost see the cold circle the room as each developer caught the virus under constant attack from coughing or keyboard sharing. What Ken hasn't grasped as of yet is that pairing is a very integral part of XP. No pairing, no XP. Robert Martin has already pointed out that "Agile" really means nothing at all at this point. There's no standard or definition that one can look to besides the vague "manifesto", so we really can't even talk about it from that angle.
If you take time to read the extremist's line on pairing, you'll see that much effort goes into deciding what to do, if anything, to people who refuse to pair. In general, the XP advice seems to be either get rid of them or send them off to do something non-project related. The "wired" article even suggests that people who don't enjoy pairing suffer from a genetic defect, autism. But the real genetic defect is gullibility, and it's running rampant in the developer community, and even appears to affect the older (and should be wiser) crowd.
Ken is correct when he says that pairing is not for everyone. However, it seems to work for more people than you might suspect; if they are willing to give it an honest try. We find that only one in twenty programmers dislike pairing so much that they refuse to continue after trying it. About one in ten programmers start out being strongly resistant to the idea, but after trying it for a couple of weeks about half of them find that pairing helps them.
The other thing to keep in mind is that most XP teams seem to back down from 100% pairing. We find that mature XP teams will pair between 70% and 80% of the time.
Ken is also right that there are many ways to get two sets of eyes on the code. And if you really cannot pair, then these options should certainly be used. However, there is a magic to pairing that should not be missed. In my experience two people working concurrently to co-author a program work better, faster, have more fun, and get more done.
I don't think I said that "agile" means nothing. I think the signers of trhe agile manifesto knew what they meant, and still know what they meant. My fear is that the word is being hijacked. That does nothing to weaken the initial concept.
As for germs, they are a cost of living and working in a community. We accept this cost in our families, schools, and workplaces. If we are courteous, we take care not to spread germs to others. We hope that others extend that same courtesy to us.
There were some unfortunate things written about pairing in the early days. However, experience has shown that mature XP teams do not take the hard line as much as those writings might have suggested. Though pairing is still very common in XP teams, it is not an absolute.
Previous Topic
