Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Can developer productivity be measured?

stackoverflow.blog

Post reply on HN
Print view View original

101–110 of 159 posts

Re: Can developer productivity be measured?

#101

Post by tyu2 »

BlargMcLarg wrote: post #80
sytse wrote: post #76

The article argues that there is no useful measure that operates at a finer grain than “tasks multiplied by complexity”. I think that complexity is hard to measure and therefore easy to game. At GitLab we only measure tasks completed, the number of changes that shipped to production, with the requirement that every change has to add value. This measure has been used throughout R&D https://about.gitlab.com/handbook/en…

Your proposed law has been tried for many years, by just as many good-willed people who believed their measures would result in target increases. In fact, the entire industry is being bombarded by one such methodology that includes those measures: Scrum. Must we really repeat the years of complaints, criticism and debates to show any measure can get warped and gamed to the point it only vaguely resembles a tool of pr…

> how do you encourage them to tackle bigger technical problems? Those that lay the foundation for the new people to do their job more easily and on-board quicker?

Isn't gitlab known for disastrously poor infrastructure with all the long outages? I.e. the exact things where people need to take their time to tackle bigger technical problems, not complete short tasks. I guess this attitude explains it, at least partially.

Re: Can developer productivity be measured?

#102

Post by [deleted] »

1123581321 wrote: post #60
carapace wrote: post #47

I once talked to a retired hardware engineer, a fellow who made real electronic devices, not software. He told me that, over the whole course of his career, 80% of the projects he worked on never made it to market. In other words, 4/5th of his total "productivity" turned out to be waste. Make of it what you will.

He could not have chosen to only attempt the successful projects.

[deleted]

Re: Can developer productivity be measured?

#103

Post by jeffbee »

pingpongchef wrote: post #89
jeffbee wrote: post #52

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriousl…

Not making mistakes isn't productivity, that's the bare minimum of acceptable behavior.

You'd think so but I've met a lot of programmers who just sit there and type out inadvisable programs non-stop.

Re: Can developer productivity be measured?

#104

Post by Bjartr »

pingpongchef wrote: post #89
jeffbee wrote: post #52

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriousl…

Not making mistakes isn't productivity, that's the bare minimum of acceptable behavior.

People aren't perfect. Mistakes abound. If the bare minimum for a position was "no mistakes" you'd never find a qualified candidate. I'll go further and add that your attitude makes things worse in practice because since mistake can, and do happen, your wholesale rejection incentivizes effort spent hiding mistakes and scapegoating. That's effort that could have gone into getting useful work done.

Re: Can developer productivity be measured?

#105

Post by bhuber »

jeffbee wrote: post #52

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriousl…

This isn't at all universally true, it depends on the costs of failure. If you're programming a Mars rover, then sure, avoiding mistakes is paramount. If you're writing a one-off data analysis script that only has to work once and only has to be mostly accurate, spending a week coming up with the ideal specification and writing a full comprehensive test suite is usually much less productive than hacking at it for a few hours until it works. Good software developers know when to make the appropriate safety tradeoffs given the goals and constraints of the task at hand.

Re: Can developer productivity be measured?

#106

Post by jeffbee »

bhuber wrote: post #105
jeffbee wrote: post #52

Productivity as a software developer consists chiefly in not making mistakes. That can lead to the situation where your best developers may appear to do nothing for long stretches. Research and deliberation are desirable. Blind hacking is the least valuable yet most visible activity of inexperienced programmers. All common "objective" measures of productivity such as closed tickets, lines of code, or PRs are seriousl…

This isn't at all universally true, it depends on the costs of failure. If you're programming a Mars rover, then sure, avoiding mistakes is paramount. If you're writing a one-off data analysis script that only has to work once and only has to be mostly accurate, spending a week coming up with the ideal specification and writing a full comprehensive test suite is usually much less productive than hacking at it for a f…

That's a straw-man retort. I never said every task requires one to go up a mountain. I only said that sometimes a software developer has reason to stop and think.

Also I would suggest that ad-hoc analyses and other such hacks are unlikely to lead to PRs and other visible artifacts.

Re: Can developer productivity be measured?

#107

Post by lgunsch »

awinter-py wrote: post #97

love the classic 'are story points hours / no / then wtf are they' conversation when PMs intro jira + cousins have never been sure how summing together something that is supposed to have no relationship with time magically provides an estimate of anything also not sure why teams are using the central source of truth for progress as the 'daily todo list making' tool I live in the real world so I estimate in hours

The answer is in the article itself. It gives you real historical data so you can predict how long the project will take with evidence, rather than just a feeling, hope, or guess.

> Velocity is an aggregate measure of tasks completed by a team over time, usually taking into account developers’ own estimates of the relative complexity of each task. It answers questions like, “how much work can this team do in the next two weeks?” The baseline answer is “about as much as they did in the last two weeks,”

If there's one thing the last 50 years of software development has conclusively proven, is that estimating the number of man months (hours) a project will take doesn't work.

Re: Can developer productivity be measured?

#108

Post by bhuber »

jeffbee wrote: post #106
bhuber wrote: post #105

Earlier quoted context omitted.

This isn't at all universally true, it depends on the costs of failure. If you're programming a Mars rover, then sure, avoiding mistakes is paramount. If you're writing a one-off data analysis script that only has to work once and only has to be mostly accurate, spending a week coming up with the ideal specification and writing a full comprehensive test suite is usually much less productive than hacking at it for a f…

That's a straw-man retort. I never said every task requires one to go up a mountain. I only said that sometimes a software developer has reason to stop and think. Also I would suggest that ad-hoc analyses and other such hacks are unlikely to lead to PRs and other visible artifacts.

I should have been more clear; I was mainly disagreeing with your first sentence. The rest mostly makes sense to me. Ad-hoc analysis was only one example, you could easily replace it with working on a prototype, where part of your goal is to find mistakes by making them, as that is often the most efficient way to discover what the problems with your design are.

Re: Can developer productivity be measured?

#110

Post by username90 »

commandlinefan wrote: post #37
BrandonMarc wrote: post #5

He mentions increasing salary won't lead to increased productivity ... and that's true, if the same developer remains. But what if we remove that constraint? What if increased salary means a higher quality of developer takes the position? Wouldn't this mean higher productivity? Bit of a cold scenario, but one way to game it out is hypothetically removing the current dev and then hiring someone better at double the pa…

> hiring someone better at double the pay Well... if you knew how to spot somebody twice as good as the one you have now, why didn't you hire that guy in the first place?

Because he demanded twice the salary?
Post reply on HN