undefined | Better HN

0 pointshammock1y ago0 comments

You’re responding to the headline, not the article. The article has a plainly stated thesis: “Even if it could be measured, productivity in software does not approximate business value in any meaningful way”

0 comments

theamk1y ago

The article contains this sentence, yes, but the rest of the text does not support it.

The article argues that lines-of-code is bad metric, and no one argues about this.

thuanao proposes measuring "number of completed projects", and I think it's a pretty good metric in some situations which don't involve long-term maintenance.

One example I can come up with is data science: two engineers are given identical requirements to ingest the data (once) and calculate certain metrics. If the assignments are identical, we can calculate and compare their productivity, in "projects/month"

lucianbr1y ago

Long-term maintenance is a confounding factor of course. People sometimes write software faster with the downside that it wil be harder to maintain.

So remove the confounding factor (at the same time removing most projects we would like to apply this to) and it becomes an easy problem?

But there are many confounding factors. Your data science project results will be different (different metric values outputed) and you don't know which one is correct, or closer to correct. Now how does the "projects/month" number look?

Or maybe one of the engineers uses way more compute-hours for getting the job done. Their projects/month number is better, but is that really a better outcome? Compute is not free.

By the time you remove most confounding factors, the productivity measure will only apply to an insignificant number of projects.

j / k navigate · click thread line to collapse