Back in 1995 or 1996, I spent a long week-end doing extreme pair programming with Philip Nelson. We set up in his dining room and took an image from his whiteboard to a 80+% done product in 3 or 4 days. No meetings, no phone calls. With very few interruptions, we were able to maintain focus for hours.
The most notable interruption: while stretching, Phil accidently hit the rocker switch on the power strip with his foot. I'll never forget the look on his face when everything shut down. We only lost a couple minutes worth of edits, 'tho. I am a habitual save guy in emacs, whenever I switch buffers or pause to think.
Though not nearly as intense as the experience related in this anecdote, it is that same compulsion to maintain focus that makes pair programming so valuable for me ... and so difficult and uncomfortable. No doubt in my mind, though: I write much better code when I'm pairing with another developer.
People are wired rather differently. Yes, you don't procrastinate to HN, Facebook, OKCupid or whatever's your online crack, but on the other hand the programming itself is an order of magnitude worse (and feels twice as bad). Maybe with a few programmers in the world I could "co-flow" enough to get up to speed, but that would still waste the other person's productivity. Considering that nice little XPers should swing a lot, this makes this probably the worst "agile" practice I know of, beyond even TDD.
Like I said, some people might be wired differently. Although in this case, it's hard to imagine getting a > 200% productivity increase out of two people to make it worth it in the long run.
For short code golfing sessions, sure. That's been called "could you help me with this code?" for a long time, before that nice alliteration was invented.
"it's hard to imagine getting a > 200% productivity increase"
It depends on how you measure productivity. If it's measured in LOC/hour or something, then pair programming will definitely seem like a huge productivity hit.
If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.
As with most Agile claims, I'd like to see that proven first. Even then I might wonder whether it's the right thing for me, but at least we could have some numbers how this works out in general.
If you've got a high fault rate, two people working things out might improve things enough to be worth the while. Especially in a case were uncaught bugs are really band and/or your daily coding is an exercise in tedious input checking, c.f. some web sites and conventional GUIs.
And even then I'd say that the occasional meeting plus a decent code review process would probably be as effective, without the hit in performance. Never mind the sheer annoyance a lot of people would feel having to "couple" all the time.
>If you measure productivity more like "features delivered per month" (and negatively adjust for bugs that make it to production) I contend that pair programming will probably yield more favorable numbers.
There's no credible evidence to support that claim.
On the other hand, pair programming generates a lot of churn (discussions about details between the pair programmers, the outcome of which bears little consequence on the solution of the problem) and that alone is guaranteed to negate whatever gain you could expect from pair programming.
In my experience, asynchronous code reviews work a lot better.
And my experience contradicts it. So what? The burden of proof is on the people claiming that it's more productive to do pair programming all the time, rather than just doing code reviews, collaborating when you need it, and otherwise not cutting your team in half. eXtreme claims require extreme proof.
Great point. Each pair will usually find the right balance of pairing time and breaks, but using the Pomodoro technique (http://www.pomodorotechnique.com/) is probably a good place to start.
I don't think the uncomfortable aspects of pairing are unique to pairing as much as they are compressed in a much shorter space. No snarky emails during code reviews or awkward hallway conversations. It's all right there, in real time.
I _really_ love hacking on code alone, but every pairing session I've had has been memorable and the code has most certainly been superior to what I would have done solo.
Second the pomodoro technique--it's almost weirdly effective. That said, I haven't tried it yet with anyone at work--but for solo stuff, it's been amazing.
How effective is pair programming when there is a skill and/or experience disparity between the two programmers? Will the worse/newer programming only hold back the better/more experienced programmer? Note: I'm not suggesting such was the case here.
I'm sure it depends, in my experience, the best way to learn is from a more experienced programmer. I would make the newer programmer drive so he doesn't end up twiddling his thumbs.
So I'd say, no, the newer programmer will not hold back the more experienced, more likely the newer programmer will just learn a lot.
(This assumes the newbie has previous experience with IDE/typing, is not actually 'worse' in the 'stupid' sense, but just less experienced).
Before you get too excited, it's obviously an exaggeration. Like on TV they don't show Jason Bourne taking a break from assassinating people to go to the bathroom.
I guess getting the code down to 100 lines was just a side effect. They first had to find out what they wanted to achieve in the first place --- including all the nitty-gritty details.
After a while they probably understood their domain. The number of lines just shows this understanding.
I've been here for more than a year, so I hope the general public will not mind me voicing a concern. In my opinion, something unwelcome is happening in the last couple of days. I think there even was a pun thread the other day...with upvotes.
Being a lurker by nature, I don't possess the power of the down arrow or the flag, so let me just say that now is not a good time to let these tools lay idle.
What's the problem with this comment specifically? Instead of saying "HN sux, everyone behave differently", why not just disagree with the comment?
I will argue both sides. For:
"It's a good point; at some point biology has to take over and break your concentration. Did they have bathroom breaks and not mention it? Were they so focused that they couldn't hear their body telling them to let it out? Did they just go in a bottle right there?"
Intersting point, jrockway!
Against:
"I think the point of this story was not to literally describe the exact events that took place over the 10 hours they were working together. They took breaks. They got some lunch and made some coffee. But that part isn't very interesting to talk about, and neither of them remember it because it was so meaningless in the context of what they were doing.
But yes, they used the bathroom. Glad that that's all you could think about."
See how I could argue either side and I didn't have to mention HN at all? If I disagreed, other people would see that and upmod me and realize that the OP's comment didn't have much relevance. If I agreed, other people might think, "hey, this OP guy is insightful".
You can control how comments are moderated and how the conversation flows. But you have to put more effort into it than just saying "HN is dying, OH NOES".
The point is that both of those responses, as well as the original remark, are completely inane and boring. If a person reads this anecdote and the only thing he has to say about it is a commentary on bathroom breaks, then I wish that person would resist the urge to post his thoughts.
Wow, a quick comment generated so many downvotes and spawned a meta mini-thread. Downvotes are perfectly fine as I'm no stranger to them. Would I change my comment style to please the hivemind? No, having different viewpoint however unpopular is important.
As for the bladder comment, yes, that's the first thing came to my mind when I read it. Guy Steele stressed strongly about they didn't take a break during the entire time of the 10 hours. I thought, not even a bathroom break? these guys must have strong bladders, or the story was embellished to make it superhuman interesting.
Note that I have enormous respect for both GS and RMS. Sure I could have said how awesome their hacking session was, but that's just being part of the echo chamber. I rather posted my honest reaction. You can read it as an admiration for their superhuman effort or as a questioning of the absurdity of a folklore.
Well, of course not. This was the 70s, and we are talking about Guy Steele here; so they were probably far too busy scheming to make smalltalk.