Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against Pair Programming

matt-rickard.com

Post reply on HN
Print view View original

101–110 of 180 posts

Re: Against Pair Programming

#101

Post by IlliOnato »

I don't have much experience with pair programming in general, but I have some in pair debugging.

And in my experience, for a difficult debugging problem this pair debugging is a very powerful tool. It is hard to measure, of course, but I have strong feeling that the productivity of a pair is way more than a sum of individual productivity in such cases. I've seen bugs identified and fixed in hours, where both of the paired programmers believed it would take them days to fix if working alone.

Re: Against Pair Programming

#103

Post by commandlinefan »

I did work for a few months in a dedicated "everything XP" shop that included religious pair programming. There were half as many computers as there were people, so we were forced, by design, to do pair programming. It broke down really fast. If one of us needed to read some documentation, the other one would just sit and chat while the first was trying to actually learn something. We'd have to take turns reading and responding to e-mail (sometimes we could work it around bathroom breaks... BTW, it gets uncomfortable when you know around what time another person uses the bathroom and how long it takes him). We had to make sure to take lunch breaks at the same times. Most of these pairs would end up getting off on discussion tangents and not get a whole lot done.

I've seen some stupid management fads in my 30 years in this business, but pair programming is still by far the stupidest.

Re: Against Pair Programming

#105

Post by commandlinefan »

calsy wrote: post #95

Pair programming stinks, always has always will. Its another mindless initiative managers come up with because some person in the organisation who subscribes to the Agile cult (there is always one) wont stop going on about it. Like most things Agile, it treats the developer as a child who cant be trusted to get things done. It's grade school where teacher tells you it's time for 'pair programming', yeahhhh. Usually i…

> most things Agile, it treats the developer as a child

Hey, don't blame "agile" for that - blame the bastardization of what managers who live to treat other people as children (or more likely as "subjects") have turned a decent concept into.

Re: Against Pair Programming

#107

Post by anthonygd »

candyking wrote: post #53

I don't agree at all. The author only considers short term productivity and does not acknowledge the long term benefits of the skill sharing. Let's make up a metric, du (dev units), for how much a developer produces in a day, and let's say an average developer produces 100du per day. If we have two developers, Sally and Frank, producing 120du and 70du respectively. Short term, for these two people to pair program, th…

> I would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question.

I think there's some unstated context when people talk about pair programming. Everyone occasionally wants to pair (maybe not with the term though). Pair programming didn't have a name until it started being mandated. As soon pair programming gets a mandate of some sort (% of time, part of codebase, day of week...) it becomes a stupid mistake. It's pretty useful up until that point.

Pair programming is like keyboards. I'm skeptical of anyone who brings up the topic: it doesn't need to be discussed.

Re: Against Pair Programming

#108

Post by mrtranscendence »

I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a minute.

When I've had to program with another person watching, my productivity screeches to a halt.

Re: Against Pair Programming

#109

Post by tlarkworthy »

mrtranscendence wrote: post #108

I can understand that some people enjoy pair programming, and there are some situations like knowledge transfer where it may be appropriate. But I'm not sure it would fit with the way I solve problems. I don't know what I'm doing half the time -- I have to experiment and hit my head against the wall and continually inspect APIs in an IPython repl. I go back and forth between a console and a browser and emacs a mile a…

Maybe they will have some helpful suggestions or techniques that will speed up that process...

Re: Against Pair Programming

#110

Post by falcolas »

tremon wrote: post #93
Veuxdo wrote: post #50

Earlier quoted context omitted.

> Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up. That's assuming two people pair programming would otherwise need to communicate about every individual line of code.

No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.

> ideas and thought processes behind every individual line of code

I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session.

"Alex, what were your thought processes that lead you to use 'i' for a loop variable?"

Post reply on HN