Live data from Hacker News

There's No Such Thing as Software Productivity (2012)

benrady.com

21–30 of 145 posts

Re: There's No Such Thing as Software Productivity (2012)

#21
post #9

I'm not sure I follow. So you failed to measure software productivity in lines of code, therefore it follows that "There's No Such Thing as Software Productivity"? Don't you think that giving up after n=1 attempts at measuring software productivity might be a tad too fast to draw a generalized claim of impossibility? I might argue the real lesson learned is "Lines of Code are Not a Measure of Productivity in an Isola…

Ok, but then what is a way to do it? The text gives an example to the core problem, and to argue differently requires thinking around it. In practice. I’ve seen many attempts at measuring productivity, but once you dig into them, you see they are just abstraction mechanisms above something that is similar to lines of code. I have yet to see an idea that sidesteps the core issue described in this post. Also, it applie…

Happy Customers.

All other measures are a proxy for happy customers.

Actually, happy customers is also a proxy (the real measure is profits) but measuring profits directly (in the short term) can lead to decisions that have adverse long term effects. It's too easy to increase profits in the short term by avoiding long-term expenses.

So, if you're in the business of software, the goal is happy customers. (And I use the word Customers carefully here. Not just Users who pay nothing, but Customers who spend money.)

In a business context, it's really the only thing that matters. But, of course, it can be hard to measure (are they Happy?) and relies on multiple disciplines. Production (coding), Marketing, Sales, Support, Documentation, Training- all need to be working well to make it work.

Ultimately if the big picture doesn't lead to Happy Customers (again, I stress, in a businesses context) then no-one is "being productive."

Re: There's No Such Thing as Software Productivity (2012)

#22
post #18

You can say this about any discipline. The root of the issue is that productivity for productivity's sake is meaningless, and it makes no sense to measure productivity as a general property when outputs vary . A tire factory has a distinct, singular goal: produce tires. It does this continually. Productivity is meaningful, but only in relation to a target that is typically specified by externalities (e.g. amount of d…

Seems to me you’re talking about measuring software. Once we pick a measure though, we can calculate output/input (productivity). Imagine two people tasked with producing the same software, or software satisfying the same requirements or test suite. What would you call the person who produces it faster? More productive? Measuring software in financial terms or lines of code might not be the right measurement of softw…

Depends in the coming months and years which was more stable, maintainable and extensible.

Re: There's No Such Thing as Software Productivity (2012)

#23
post #9

I'm not sure I follow. So you failed to measure software productivity in lines of code, therefore it follows that "There's No Such Thing as Software Productivity"? Don't you think that giving up after n=1 attempts at measuring software productivity might be a tad too fast to draw a generalized claim of impossibility? I might argue the real lesson learned is "Lines of Code are Not a Measure of Productivity in an Isola…

Ok, but then what is a way to do it? The text gives an example to the core problem, and to argue differently requires thinking around it. In practice. I’ve seen many attempts at measuring productivity, but once you dig into them, you see they are just abstraction mechanisms above something that is similar to lines of code. I have yet to see an idea that sidesteps the core issue described in this post. Also, it applie…

Revenue per employee $ spent.

Re: There's No Such Thing as Software Productivity (2012)

#24
post #7

> I would argue that what good software developers do is remove problems. The opposite, in fact, of production But something is being produced - it is version 2.0 of the software. This is an artifact that is then shipped to users or deployed to a server. Peter’s solution fixed the issue and did not (seemingly) create further maintenance burden, which would have taken attention away from other tasks, i.e. reduced futu…

Silly and convenient. No one takes the claim that you can’t measure software productivity seriously and everyone simultaneously agrees that simple scalar metrics often fail to show the big picture in any and all disciplines.

The rest is just usual software guy hubris and lack of awareness of the discipline.

Re: There's No Such Thing as Software Productivity (2012)

#25

You can say this about any discipline. The root of the issue is that productivity for productivity's sake is meaningless, and it makes no sense to measure productivity as a general property when outputs vary . A tire factory has a distinct, singular goal: produce tires. It does this continually. Productivity is meaningful, but only in relation to a target that is typically specified by externalities (e.g. amount of d…

Isn't the output, the singular goal, always money? (As sad as that may be.)

Re: There's No Such Thing as Software Productivity (2012)

#26
post #9

I'm not sure I follow. So you failed to measure software productivity in lines of code, therefore it follows that "There's No Such Thing as Software Productivity"? Don't you think that giving up after n=1 attempts at measuring software productivity might be a tad too fast to draw a generalized claim of impossibility? I might argue the real lesson learned is "Lines of Code are Not a Measure of Productivity in an Isola…

> it kind of massages our ego, like yes, they can measure other sorts of productivity, but not ours, oh no, we're too complex and intelligent, there's no way to measure the deep sorts of work that we do! Which, yes, OK, we're not exactly bricklayers, but surely, if you had to, you could do better.

Productivity is not a cut-n-dry stat for any kind of knowledge work.

For an admin, we could say they were more productive if they handled more cases than last month. But this does not account for tricky cases or ambiguous cases, which might have taken 2x time to sort out but on rote numbers it looks they were less productive.

For us, there are no specific goals(except arbitrary imaginary deadlines by clueless management and sprint points) to correctly measure productivity. A junior engineer may spend 4h each day blasting out many lines of codes, a mid/senior may spend more hours in reviews or meetings. A 5 line PR with test coverage is faster to review than a 800+ LOC PR with additional tests and have significant risk of breaking something, so review number is also not a good indicator. I need to coordinate with min. 12 people to get any new credentials or access to specific env owned by another team, which is not countable as productive but unavoidable. How about that garbage meeting where I was just spending time yawning because some new tech lead who believes that a modular monolith system is better if it was rewritten as event based. Productivity measurement is hard.

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?

Re: There's No Such Thing as Software Productivity (2012)

#27
post #18

You can say this about any discipline. The root of the issue is that productivity for productivity's sake is meaningless, and it makes no sense to measure productivity as a general property when outputs vary . A tire factory has a distinct, singular goal: produce tires. It does this continually. Productivity is meaningful, but only in relation to a target that is typically specified by externalities (e.g. amount of d…

Seems to me you’re talking about measuring software. Once we pick a measure though, we can calculate output/input (productivity). Imagine two people tasked with producing the same software, or software satisfying the same requirements or test suite. What would you call the person who produces it faster? More productive? Measuring software in financial terms or lines of code might not be the right measurement of softw…

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”

Re: There's No Such Thing as Software Productivity (2012)

#28

You can say this about any discipline. The root of the issue is that productivity for productivity's sake is meaningless, and it makes no sense to measure productivity as a general property when outputs vary . A tire factory has a distinct, singular goal: produce tires. It does this continually. Productivity is meaningful, but only in relation to a target that is typically specified by externalities (e.g. amount of d…

Isn't the output, the singular goal, always money? (As sad as that may be.)

Money is the measure of usefulness.

By the way, why suddenly the money=bad sentiment is so popular? I thought USSR example loudly showed us what happens when people think that money is evil.

Re: There's No Such Thing as Software Productivity (2012)

#29

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.

Re: There's No Such Thing as Software Productivity (2012)

#30
I realized why this post rubs me the wrong way.

It complains, but doesn't offer a solution. It simply criticizes and says "all engineers cannot and thusly should not be measured".

The ironic thing is, the blog post is implicitly measuring by not explicitly measuring. The measurement is the bug ticket itself and whatever value attached to it.

But to this end, I generally agree. There are qualitative and quantitative measurements. Quantitative is the value of the ticket commonly ascribed by the team (scrum? agile? whatever). Qualitative should come up in review.

Qualitative is SO HARD. Top down? Team 360? Mixed? But it must be undertaken and refined by the team at each level of the org. Otherwise you will run into the exact situation described by the blog post and you won't know how to judge left from right, good from bad. Maybe the blog post's example isn't that great, too much information is missing to make a solid judgement, but you need to decide who to reward via promotion, annual raises and who to reprimand and who to not change.

But still, all systems are terrible, but you must pick one less it be picked for you.

Post reply on HN