6 ms·

Extreme Pair Programming - Guy Steele and Richard Stallman

82 points by r11t 16y ago

rsbrown 16y ago
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.
- briandoll 16y ago
  Great point. Each pair will usually find the right balance of pairing time and breaks, but using the Pomodoro technique (http://www.pomodorotechnique.com/ 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.
  - happy4crazy 16y ago
    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.
- mhd 16y ago
  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.
  - rsbrown 16y ago
    "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.
    - mhd 16y ago
      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.
    - billmcneale 16y ago
      >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.
      - rsbrown 16y ago
        "There's no credible evidence to support that claim." My experience supports it. Can you point to credible evidence to support your claim?
gaius 16y ago
I'd pay to see ESR and Zed Shaw pair-programming.
- mhd 16y ago
  This might be a rather short session, I don't think Zed carries.
  - alnayyir 16y ago
    Carries?
- alnayyir 16y ago
  I'm not sure ESR codes much.
- daniel-cussen 16y ago
  Stands for Eric S. Raymond.
brettmjohnson 16y ago
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.
- eru 16y ago
  Doesn't emacs even save automatically (in a temporary file or so)? I know that vi does.
  - tommynazareth 16y ago
    Of course. But when you use Emacs regularly, you start typing CTRL-X-S constantly, even when you're not in Emacs.
jpablo 16y ago
10 hours code golfing to get the code down to 100 lines ? Seems kind of extreme.
- adamtj 16y ago
  "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
- jrockway 16y ago
  Seems worth it considering the hundreds of millions of times that code has been executed and hacked on. Sure, write your YAGNI version in five minutes, but don't expect anyone to help you. When you put effort into your public code, others will too.
- eru 16y ago
  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.
koeselitz 16y ago
[from link:] "Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk." 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.
ww520 16y ago
TIL Strong bladder is a prerequisite doing pair programming with RMS.
- munchhausen 16y ago
  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.
  - jrockway 16y ago
    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".
    - mquander 16y ago
      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.
baddox 16y ago
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.
- ohyes 16y ago
  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).
checoivan 16y ago
For some reason I can't explain... the idea of 10 hours of coding without interruption ,just cranking stuff, and loosing track of time excites me :)
- gaius 16y ago
  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.
  - stuhacking 16y ago
    Didn't he once assassinate someone in a bathroom? :)

82 points by r11t 16y ago

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.

briandoll 16y ago
Great point. Each pair will usually find the right balance of pairing time and breaks, but using the Pomodoro technique (http://www.pomodorotechnique.com/ 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.
- happy4crazy 16y ago
  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.
mhd 16y ago
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.
- rsbrown 16y ago
  "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.
  - mhd 16y ago
    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.
  - billmcneale 16y ago
    >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.
    - rsbrown 16y ago
      "There's no credible evidence to support that claim." My experience supports it. Can you point to credible evidence to support your claim?

gaius 16y ago

I'd pay to see ESR and Zed Shaw pair-programming.

mhd 16y ago
This might be a rather short session, I don't think Zed carries.
- alnayyir 16y ago
  Carries?
alnayyir 16y ago
I'm not sure ESR codes much.
daniel-cussen 16y ago
Stands for Eric S. Raymond.

brettmjohnson 16y ago

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.

eru 16y ago
Doesn't emacs even save automatically (in a temporary file or so)? I know that vi does.
- tommynazareth 16y ago
  Of course. But when you use Emacs regularly, you start typing CTRL-X-S constantly, even when you're not in Emacs.

jpablo 16y ago

10 hours code golfing to get the code down to 100 lines ? Seems kind of extreme.

adamtj 16y ago
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
jrockway 16y ago
Seems worth it considering the hundreds of millions of times that code has been executed and hacked on. Sure, write your YAGNI version in five minutes, but don't expect anyone to help you. When you put effort into your public code, others will too.
eru 16y ago
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.

koeselitz 16y ago

[from link:] "Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk." 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.

ww520 16y ago

TIL Strong bladder is a prerequisite doing pair programming with RMS.

munchhausen 16y ago
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.
- jrockway 16y ago
  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".
  - mquander 16y ago
    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.

baddox 16y ago

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.

ohyes 16y ago
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).

checoivan 16y ago

For some reason I can't explain... the idea of 10 hours of coding without interruption ,just cranking stuff, and loosing track of time excites me :)

gaius 16y ago
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.
- stuhacking 16y ago
  Didn't he once assassinate someone in a bathroom? :)