4 ms·

It's very, very hard to do objective research on this topic. There are tons of reasons that LoC isn't a great way to measure productivity, including the times w

It's very, very hard to do objective research on this topic. There are tons of reasons that LoC isn't a great way to measure productivity, including the times when you refactor existing code such that you delete thousands of lines of code, and your "LoC output" is negative for a time period. The Tale of Two Programmers is the epitome of such tales, IMO. [1] That said, most of the time developers with roughly equal skill levels end up writing new code to implement new features. And LoC is about the best metric you can use. If you factor in expert developers writing fewer LoC to achieve the same goals, then the results of the paper are magnified, because if an expert's 1000 LoC is good for 2x the number of features as an average developer's 1000 LoC, but the number of bugs is comparable, then it's an even greater advantage to use the expert. >No space given to future maintainability or bugs, only on raw productivity. They do talk about bugs; they say in the summary: "There are no significant quality benefits compared to a single programmer who uses static analysis and inspections." And later on in the paper they compare delivered defects. I'm easily in the "expert" end of the spectrum as a programmer; I've never seen a benefit in pair programming that would justify two salaries. I'm sorry, and I'm sure I'll be slammed for this, but pair programming is a crutch to boost programmer productivity of average or below average developers. "Average" developers would have to make 1/3 or less of my salary to make it worthwhile, economically. In my opinion pair programming's only valid use is in training a junior developer (or allowing two junior developers to support each other, though in the paper the bugs delivered were far worse from two junior developers than from a single expert developer -- but you can't always hire an expert developer). Otherwise it's a waste of money. If you can pull it off as a developer in some big company that has lots of money, by all means, have a blast. I thought HN was more about bootstrapping and getting code working as quickly as possible, and pair programming is not the way to accomplish that. [1] http://mail.linux.ie/pipermail/social/1999-October/000483.html http://mail.linux.ie/pipermail/social/1999-October/000483.ht...

vinceguidry 13y ago
That's a pretty good rationale. I'm not saying pair programming is good/bad, I don't have enough experience with it to be able to call it. But I do know management thinking when I see it. It's always riddled with assertions, lamp post search methodology, and clueless comparisons.
dj-wonk 13y ago
There is a spectrum of pairing possibilities. You can pair anywhere between 0 and 168 hours per week, in theory. I would not assume a linear relationship between that number and the value of pairing. :) For me, a few hours of pairing a day has a lot of value. If I could, I would do that regularly. When I use it to focus on hard problems, it can improve my thinking, it improves knowledge transfer, and it builds team relationships.
shawn-furyan 13y ago
The issue is less that LoC is universally a useless metric, and more that it's a metric whose nuances need to be accounted for carefully when used in analysis. The author gave no indication of such accounting, and so regardless of whether or not we would tend to agree with the conclusion, we should reject the analysis. Really, the biggest problem is the presentation. The whole thing reads like a back of the envelope calculation turned blog post dressed up to look like an industry white paper. If this were just a blog post with a few more caveats thrown in, it wouldn't be nearly so bad.
- SomeCallMeTim 13y ago
  It's still a Really Hard Problem. How would you account for LoC nuances, exactly? As I pointed out, the better the developer, the fewer LoC produced per "feature point" or however you want to measure it. So any analysis that doesn't take into account the nuances would be skewed against the expert developers. This would mean that, if the study purported to prove that two average programmers were more productive than an expert, I would have to take the conclusion with a grain of salt (or reject the analysis). But given that despite the disadvantage, experts were still shown to be more cost effective without pair programming? I don't see why we'd need to reject that conclusion.

vinceguidry 13y ago

That's a pretty good rationale. I'm not saying pair programming is good/bad, I don't have enough experience with it to be able to call it. But I do know management thinking when I see it. It's always riddled with assertions, lamp post search methodology, and clueless comparisons.

dj-wonk 13y ago

There is a spectrum of pairing possibilities. You can pair anywhere between 0 and 168 hours per week, in theory. I would not assume a linear relationship between that number and the value of pairing. :) For me, a few hours of pairing a day has a lot of value. If I could, I would do that regularly. When I use it to focus on hard problems, it can improve my thinking, it improves knowledge transfer, and it builds team relationships.

shawn-furyan 13y ago

The issue is less that LoC is universally a useless metric, and more that it's a metric whose nuances need to be accounted for carefully when used in analysis. The author gave no indication of such accounting, and so regardless of whether or not we would tend to agree with the conclusion, we should reject the analysis. Really, the biggest problem is the presentation. The whole thing reads like a back of the envelope calculation turned blog post dressed up to look like an industry white paper. If this were just a blog post with a few more caveats thrown in, it wouldn't be nearly so bad.

SomeCallMeTim 13y ago
It's still a Really Hard Problem. How would you account for LoC nuances, exactly? As I pointed out, the better the developer, the fewer LoC produced per "feature point" or however you want to measure it. So any analysis that doesn't take into account the nuances would be skewed against the expert developers. This would mean that, if the study purported to prove that two average programmers were more productive than an expert, I would have to take the conclusion with a grain of salt (or reject the analysis). But given that despite the disadvantage, experts were still shown to be more cost effective without pair programming? I don't see why we'd need to reject that conclusion.