71–80 of 145 posts
Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.
See: Out of the Tar Pit.
Earlier quoted context omitted.
> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc? I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my wor…
No offense but reading this comment with the utmost attempt at interpreting it in good faith, it kind of sounds like you're just going off of vibes and can't actually quantify productivity any more than anyone else can. Otherwise... How exactly are you quantifying it? If you had to show your work, could you?
Earlier quoted context omitted.
> To take your envy(I sense it on the quoted remark) to another place, think about how you go about measuring productivity of a CEO, PO, PM, Scrum Master, Agilist/Agile-Specialist etc? I have no envy; I'm a software engineer as well. I just don't seem to struggle, as others claim to, in measuring productivity. I find it fairly straightforward to see that some people are more productive than others, at least in my wor…
> I just don't seem to struggle, as others claim to, in measuring productivity. Because you are measuring at a very broad and basic level. Steve is more productive than Susan. Great. How much more productive? Can you turn it into a number? Can you still do it consistently when Steve and Susan are in different teams in different parts of the organisation trying to achieve different goals? I've done DB upgrades that to…
This is moving goalposts. OP's argument was "There's No Such Thing as Software Productivity", not "You Can't Convert Software Productivity into a Floating Point Number With 3 Decimals of Accuracy."
Sure there is. It's a ratio of inputs to outputs.. even in the example the inputs and outputs are measurable. The only thing this article gets at is that engineers may not know how to calculate their own productivity; but it doesn't means it's not calculable.
>It's a ratio of inputs to outputs.. even in the example the inputs and outputs are measurable. So more lines of code is better! Um, we know this doesn't work that way as a good measure. This is like comparing algorithms that do the same thing to algorithms that do different things. You're not going to get good valid comparisons. Metrics for one thing may not work at all for another.
It's a perfectly cromulent measure so long as we understand the limitations of the measure. For example, trying to measure the productivity of a day or a sprint? That's silly. Measure the output of a team which does not produce an entire product? Won't work because you'd have to figure out how to apportion the productivity.
Using productivity as a metric leads to the same nonsequitur stuff in many many fields.
It works somewhat for industrial output when you're working with commodities. Or it can work in some more fields as an ancillary measure if you pair it with some other quality, customer satisfaction, outcomes etc measure. But usually you don't want to maximize work while getting good outcomes, you just want the good outcomes.
Earlier quoted context omitted.
>It's a ratio of inputs to outputs.. even in the example the inputs and outputs are measurable. So more lines of code is better! Um, we know this doesn't work that way as a good measure. This is like comparing algorithms that do the same thing to algorithms that do different things. You're not going to get good valid comparisons. Metrics for one thing may not work at all for another.
The output is measured with dollars, not lines of code. So are the inputs. It's a perfectly cromulent measure so long as we understand the limitations of the measure. For example, trying to measure the productivity of a day or a sprint? That's silly. Measure the output of a team which does not produce an entire product? Won't work because you'd have to figure out how to apportion the productivity.
Eg https://www.britannica.com/money/productivity says:
"productivity, in economics, the ratio of what is produced to what is required to produce it. Usually this ratio is in the form of an average, expressing the total output of some category of goods divided by the total input of, say, labour or raw materials."
Earlier quoted context omitted.
No offense but reading this comment with the utmost attempt at interpreting it in good faith, it kind of sounds like you're just going off of vibes and can't actually quantify productivity any more than anyone else can. Otherwise... How exactly are you quantifying it? If you had to show your work, could you?
I dunno, the opposite side seems equally absurd to me. Do you work at a software company? Do you have coworkers? Are you honestly telling me that, gun to your head, you couldn't say that some are more productive and some are less? That if you had to choose a co-founder for your next startup, that you would have NO idea where to begin, that any of them would be equally as good as the next?
I stand by what I said, whether people like it or not.
Including the part about going off vibes. Please explain how this "you can just kind of tell" mentality is not literally just going off of vibes?
(And I wouldn't choose a cofounder only based on productivity, anyways. I'm not even sure that would be the main criteria.)
Earlier quoted context omitted.
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”
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 requireme…
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.
Earlier quoted context omitted.
>It's a ratio of inputs to outputs.. even in the example the inputs and outputs are measurable. So more lines of code is better! Um, we know this doesn't work that way as a good measure. This is like comparing algorithms that do the same thing to algorithms that do different things. You're not going to get good valid comparisons. Metrics for one thing may not work at all for another.
The output is measured with dollars, not lines of code. So are the inputs. It's a perfectly cromulent measure so long as we understand the limitations of the measure. For example, trying to measure the productivity of a day or a sprint? That's silly. Measure the output of a team which does not produce an entire product? Won't work because you'd have to figure out how to apportion the productivity.
The whole reason for this discussion is situations like Microsoft having 200k employees and making $240B in a year. Which employees, teams, or even departments are more productive? They want to know.
And even if it did not matter, likely the expense of this year influences the income over multiple future years, so you compare the dollars in / dollars out for which periods?