Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No one is capable of measuring programmer productivity objectively.


You can, if you have clear objectives.


Nah. It's impossible, unless you define "productivity" in such a narrow way that it ceases to be relevant to actual business value creation.


You just defined it, "business value creation", from there, you narrow it down, short term vs long term, strategic vs revenue generating, and so on.

The idea that you can't measure productivity is align with people who think "economics is not science."


Nah. It's impossible to link business value creation to individual contributors. No one has ever figured out how to do this in a accurate, reliable, and repeatable way. When it comes to knowledge work, productivity can only be measured in aggregate for larger groups.

Most of economics is junk science. Very little of it is quantitatively rigorous or falsifiable in the real world.


I think it’s possible some of the time for some projects to measure how much business value an IC created.

But I also think there is no company with more than 50 software engineers employees that is able to accurately attribute business value creation to the majority of their software engineers.

Software engineers rarely pick what they work on, so in most cases you can only measure how well they meet the objectives they were assigned to work on.

And even then you can only get any kind of accuracy at the team level.

And those numbers aren’t comparable between teams because teams aren’t assigned to work on the same things.

People who think they can accurately measure things like velocity will bring out arguments based on the law of large numbers. But that only works when the number of samples is much larger than the number of variables, which is not the case for software engineering.

You can believe that economics is science. But still believe that it’s impossible to figure out how much GDP growth is attributable to each individual member of congress.


> Software engineers rarely pick what they work on, so in most cases you can only measure how well they meet the objectives they were assigned to work on.

There it goes, your other metric.

> People who think they can accurately measure things like velocity will bring out arguments based on the law of large numbers. But that only works when the number of samples is much larger than the number of variables, which is not the case for software engineering.

You can't accurately measure any coastline, but we don't stop at that.


>There it goes, your other metric.

1. It’s impossible to measure that except in aggregate

2. The only thing you can actually measure is how soon did it launch because the quality of the thing is too wrapped up in what it’s supposed to do.

How many bugs were there? That’s heavily dependent on how complicated the problem it’s solving.

The absolute best thing anyone has come up with is velocity, which just measures how good a team is at estimating. That also only works at the team level and it’s only accurate for teams repeatedly doing similar work that haven’t changed in composition for years.

> You can't accurately measure any coastline, but we don't stop at that.

We actually can accurately measure the relative lengths of coastlines such that we can compare them by picking a measurement resolution and using that for all of them.

You can’t do that here. It doesn’t work.

If we could accurately map business value creating back to ICs, tech companies would look very very different.

Even if you could objectively measure how good an IC is at meeting objectives. The developers I’ve met who were best at that metric tended to be terrible at their jobs in general because they’d just take anything product wanted and build it exactly as described.

So you want some amount of pushback. But not too much or they just end up not doing anything.

Try to come up with a metric for that. To do that though it needs to be normalized by how good the PM is at designing features. If the PM was terrific, you wouldn’t want pushback.

So now you have to rate all your PMs before you can rate your ICs. Then you need to rate the PMs bosses and so on. Until you have an uncomputable mess.

The best you can do is have enough EMs so they can get a feel for how ICs are doing. You can also probably expose the absolute worst performing engineers with metrics because they’re just literally doing nothing. But even then, you’ll get some false positives.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: