5 ms·

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 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.