I had fairly bad experiences with pair programming. None of the physical reasons the author brought up applied: it was in a decent, private room, with decent hardware. The social problems did not apply: it was with cool, friendly people.
It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs.
One more thing. The author claims that pair programming helps avoid duct-taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"
Some replies to your comment demonstrate exactly why I'm not a fan of forced pairing advocacy and the arguments they use. It borders on the religious: "I love pair programming. Try it, you will love it too"
When someone doesn't experience the unbridled joy of pair programming salvation, it is always something wrong with them, their task, or their partner. Essentially, "oh you weren't pairing correctly" -> "you didn't have enough faith".
Is there any possibility pair programming advocates can cede that developers can eschew pair programming and still produce quality code?
Since I wrote one of the "here's how you could fix your pair programming" replies, I should clarify that I don't think pair programming is the only way to work. I'm not doing it in my job right now and don't particularly think I should be.
If you are pair programming either by choice or circumstance, it's useful to know some tricks to make it work better. But if you've tried it and don't think it's the right thing, then you should do something else.
I see what you're saying, and I agree to an extent, so i hop my comment didn't sound religious. All I meant was, if someone is typing, and someone else is watching, and no one is talking, then you aren't doing what any reasonable person would call "pairing".
Don't dislike practices because there are people who are passionate about them.
How you organize a team is up to you, but pair programming does remain a highly effective tool for some teams. It certainly beats change control boards.
No matter how long you've been programming solo, you can't expect to sit down with a pair and have it "just work". Sure, it happens sometimes, but if it doesn't, you should practice it a bit before discounting the idea.
There are a few things the navigator can do to help out the driver while the driver is typing, but I hesitate to focus on them. In general, both programmers should be engaged. Learn to talk out ideas with your pair in short segments.
TDD helps. Test driving code naturally gives your pair many opportunities to inject their ideas without ruining your train of thought (ie: stop and discuss things at least after every test, preferably much more, but that comes with practice).
Absolutely. It took me four years of misstarts and agony (2000-2004) to really understand and get good at pair programming. During that time I mostly kept the faith about it since I was a zealous XP advocate, but had a large measure of doubt about its true effectiveness.
It took working with talented pair-programmers at ThoughtWorks to really make it click.
"During that time I mostly kept the faith about it since I was a zealous XP advocate, but had a large measure of doubt about its true effectiveness."
Revealing sentence.
You "had a large measure of doubt about its effectiveness" but since you were a "zealous advocate" (of something you were doubtful about!) you mostly "kept the faith".
Sounds pretty hypocritical and manipulative. How are we to believe your "zealous" declarations now?
No wonder agilists are often dismissed as "One True Way" religious fanatics.
If you find one person being "passive" in a pair session, you can switch drivers, so the person at the keyboard and the person who wrote most of the code so far are different. Or you can try something like the TDD Game (or any other format where one person writes tests or tries to break the code as the other writes it): http://www.peterprovost.org/blog/post/The-Pair-Programming-T...
What kind of code was that? It sounds like churning out boilerplate stuff in flow state. The passive one should be able to join to debug failing unit tests and to listen to your thoughts.
I pair program every day, and this is not a typical experience for me.
When I pair I'm having an active discussion with the person I'm pairing with about what piece of functionality we're implementing. We don't rubber-stamp things for the sake of it.
If my pair has a great idea on how to do something and I don't, I let them run with it, and then maybe I have an idea that builds on top of that, which I may not have figured out on my own. I'm analysing what they're doing, thinking of ways to improve it as they go.
This idea of one person just coding away while the other person sits there is a mystery to me. If one person is 'passive', you're doing it wrong.
Pairing has helped me and my code a lot but as with most things there is a learning curve. Only an atrocious pair would say something like "Oh... yes, that function... I already thought of that, and here's why it can't work.". When pairing, thinking is talking. If the one not typing at the moment is allowed to get bored, then the pairing is not done correctly.
Also, in my experience, two developers working as a pair will have better work ethics and discipline than any of the two taken separately.
BTW, you're calling the one not typing the 'passive' one? That's the wrong attitude.
When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"
Really? In this context, I find that I'm the one who often says, "will someone understand what this is doing when they see it the first time?" When it's just me, I may not stop to consider that POV.
Equally you could point to numerous systems not developed using any form of peer review and conclude the opposite. In the matter of fact there's probably more bad systems hacked together by solo programmers than there are written by communicative teams.
Systems that have no review of any kind are normally the ones that fail. Whether you are pairing or submitting to opensource where your code is checked, the quality goes up because things are checked.
The more effective the communication the better the software. If two teams don't work well together, that is reflected in the software.
I think you didn't have the type of pair programming experience which is described in the article. I've long ceased being a vocal advocate of pair programming, but when done well, you're having an ongoing dialogue with your pair partner. If the code isn't amenable to working that way, or if you or your partner aren't amenable to working that way (i.e., thinking out loud almost constantly), then it's probably a poor choice for you and your group.
In a healthy environment, I prefer pairing, for most of the same reasons that are described in the NYT article. But it's not for everyone any more than red crewneck shirts are for everyone.
It turns out that, in pair programming, while the active person hacks with all his neurons firing, the passive one sits bored out of his mind. I found that passively following someone else's programming, and possibly even fixing minor mistakes, barely uses up a fraction of the mental energy of actively coding. The passive ends up being a distraction. When the passive makes a comment ("have you considered changing this function to do XYZ?"), the active looks up, completely distracted and torn from his concentration, and stares at the passive. "What?.. What did you say?.. Oh... yes, that function... I already thought of that, and here's why it can't work." Basically, I found that being passive in a programming pair also blocks the kind of forward-thinking analysis which leads to good programs.
One more thing. The author claims that pair programming helps avoid duct-taping problems. I completely disagree, at least when it comes to my own work. When I look at my code, and I see the beginnings of something bad, I ask myself: "Could someone else understand this in two months? Will I, when it breaks?" Then I go back and fix it. Whereas in pair programming, two people will likely look at each other and say, "Oh yeah, that's an obvious workaround! Let's keep going!"