[pixl97]

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

[cjensen]

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.

[fulafel]

That's not the definition.

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

[cjensen]

It's implied in the definition. Consider the units: a ratio should not have units. Lines of code per programmer per day would have weird units, for example, and could not be compared against number of windows installed per day for per car window installer. The only way for productivity to be useful is to normalize the inputs and outputs into money.

[lucianbr]

It's a perfectly good measure except it does not help us at all.

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?