Productivity to me is about choosing the best tradeoff while minimizing the costs of going ahead.
There's No Such Thing as Software Productivity (2012)
31–40 of 145 posts
Re: There's No Such Thing as Software Productivity (2012)
#32I'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…
> 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 workplace where we can hold most things constant (e.g. meeting count, managerial ability, etc, etc). Yes, there may be external factors, and that's unfortunate. Yes, it's not fair that some people are more productive than others despite putting in half the effort. But I'm not going to stick my head in the sand and pretend it's invisible.
Re: There's No Such Thing as Software Productivity (2012)
#33So if you have a developer who writes no code and closes no tickets, who essentially does nothing except come to meetings, they are just as productive as a developer who writes some code and closes some tickets? Obviously there is a difference there. Negative code is still doing something as well. Back in the 90s we used Personal Software Process from the SEI, and we measured lines added, deleted, and changed. (as well as defects removed and added)
It becomes clear that simple quantity of code and tickets is not enough- but it's also not nothing. Part of what is missing is quality and assessments of task complexity. Part of what is missing is the other parts of the jobs, like design and code reviews.
I don't think it's hopeless, and can at least be used to look into why some people don't seem to make much at all.
Re: There's No Such Thing as Software Productivity (2012)
#34You 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…
[deleted]
Re: There's No Such Thing as Software Productivity (2012)
#35And yet, Jeff Dean is significantly more productive than I am.
Re: There's No Such Thing as Software Productivity (2012)
#36I'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…
> 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?
Software developers should look at anyone claiming they can measure software productivity as a snake oil salesman.
We have seen hundreds of attempts over the years and they have all "failed". More accurately they all have large error bars and biases.
Researchers can and should continue looking into how to measure software development productivity. It is likely over the next few decades we will start to understand how to measure it appropriately.
Re: There's No Such Thing as Software Productivity (2012)
#37Solving problems is productivity. That also means, solving them in a way that the solution doesn’t spawn new problems down the road, which is why we should follow the
best practices. I can’t say whether deleting 100 lines is better than adding 1K lines, because before passing that judgement I would need to see what exactly those 100 and 1K lines are. OP is arguing too black and white IMO, and draws the conclusion before I‘m sold on the premise.
Re: There's No Such Thing as Software Productivity (2012)
#38Earlier quoted context omitted.
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.
When companies focus on profit at the expense of all other goals, the result is typically disadvantageous to customers, employees, and society at large.
See also: crapification; financialization; parasitic private equity
I can't speak for HN, but I imagine some readers are more interested in the benefits of cool technology beyond putting more money in the pockets of investors and management.
Re: There's No Such Thing as Software Productivity (2012)
#39Good productivity is about being able to do all tasks as planned. That includes the management, as its task is to attribute tasks. And whoever creates tasks. And whoever defines the objectives those tasks should answer to.
Re: There's No Such Thing as Software Productivity (2012)
#40I'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…
I think people get hung up on wanting to collapse developer productivity into a single dimension, usually for stack-ranking purposes. This, I think, is always going to punish good engineers and reward bad ones to some degree.
Measuring developer productivity should, in my opinion, have one dimension for speed, one for quality, and one for user impact. LOC can be fine as a measurement for speed, you just don’t want to look at it in isolation. You would want to also measure, for example, escape rate and usage for the features the developer worked on, and be willing to change or refine these if circumstances require it.
You also need to look for different profiles based on the developer’s level of seniority. A senior dev probably shouldn’t be writing as much code as a contributor, but their user impact should be high, and escape rate low. Analyzing differences between teams is important, as well. A team that has a lot of escapes or little user impact probably has issues that need management attention, and may not have anything at all to do with individual developer productivity or ability.
In brief, the numbers are there to help you make better management decisions, not to relieve you of having to make them.