There's No Such Thing as Software Productivity (2012)
1–10 of 145 posts
Re: There's No Such Thing as Software Productivity (2012)
#2Ok, but ironically the article does explain by a comparison of two alternatives just how to measure productivity—-solving problems most efficiently (least amount of maintainable code).
Re: There's No Such Thing as Software Productivity (2012)
#3Sure 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.
Re: There's No Such Thing as Software Productivity (2012)
#4the problem is that software does not directly produce value, it is a way to place a bet on what will be valuable
Re: There's No Such Thing as Software Productivity (2012)
#5the problem is that software does not directly produce value, it is a way to place a bet on what will be valuable
Pretty spot on and that is why devops stuff and automatic tests are so important. Those just let your bet faster.
Re: There's No Such Thing as Software Productivity (2012)
#6You 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 demand)
A software company is usually not in the business of producing consumable commodities so this kind of measurement does not make sense. It can make sense to measure productivity during a period for delivering a particular piece of software within a given time bound, but once it's delivered, productivity becomes meaningless. You always need to understand productivity in relation to some purpose and I don't know how these knuckleheads who think this abstract idea is basically like a concrete measurable essence, like mass, or liquid, got leadership positions.
Re: There's No Such Thing as Software Productivity (2012)
#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 future productivity.
I agree that metrics for programmer productivity are often useless (e.g. using lines of code is a bad idea for obvious reasons), but it seems silly to claim that the entire concept of productivity does not apply to the production of software.
Re: There's No Such Thing as Software Productivity (2012)
#8I do appreciate the little coda at the end - nice that the author was self-aware enough to realize where the cruft was and cut it (and courteous to the reader!)
Re: There's No Such Thing as Software Productivity (2012)
#9I'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 Isolated, Toy Example".
I suspect this sort of thing gets promulgated because 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.
Re: There's No Such Thing as Software Productivity (2012)
#10You can very well at least count the problems that were solved (or deleted) you can also probably measure the value those solutions have in revenue or another metric.
It's still true that measuring lines of code, time spent coding, commits or anything else is at best a proxy of productivity. It's also true that without any code changes problems more often than not don't get solved or we at least can't call the activity software development.