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.ht...
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.
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.
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.
But there wasn't any useful data because the source, timing, measurement practices, and sample sizes for the grand summary tables were not mentioned at all. It's like reading an article that states very firmly that the moon is made up of precisely 89.24397% green cheese. It sure sounds very specific but where DID that number come from?
I hope the author publishes more details about how these numbers were calculated because we need more data about pairing but I don't really expect that he will.
More heat than light, really.
I think the coding environment being analyzed is already well-defined and the projects being coded are one-offs being sold to clients where maintenance is done through a lucrative support contract. In this setting, a "defect" would be anything keeping the product from shipping. Anything else is overlooked and untracked.
It's the software equivalent of shoveling whatever crap you can find into a sausage casing, pricing it like fine steak, then selling your own medicine when it makes them sick.