Live data from Hacker News

Can developer productivity be measured?

stackoverflow.blog

51–60 of 159 posts

Re: Can developer productivity be measured?

#51

Earlier quoted context omitted.

Probably, but to represent the non-sarcastic point of view, it comes down to "[person] in the room" syndrome[1]. Spending 2-3 weeks on a bug is never good, if you're not communicating progress, and one way to communicate progress is to break down the work into smaller chunks. Does it literally have to be individual JIRA tickets? No way, but going off for 2-3 weeks doesn't give the business the insight it needs to in…

> Spending 2-3 weeks on a bug is never good, if you're not communicating progress Assuming that it is important to fix the bug and that the developer is competent and trusted - why not? What would communicating progress improve here? Mind that you cannot communicate when it is done (otherwise it would not be a hard bug) you can only communicate what you have done so far and what you try next. But what kind of busines…

The value is that the developer doesn’t reasonably have the context necessary to make the call whether or not, over time, the issue is worth continuing to invest time to resolve.

Not that they couldn’t make the call if they had all the info, but the time required to gather and understand all the context would be a second full-time job.

Re: Can developer productivity be measured?

#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 seriously flawed.

Re: Can developer productivity be measured?

#53
The smallest organizational unit at which productivity can usefully be measured is an agile team of about 7 people. Below that size the effort of quantifying productivity exceeds any possible value of doing so, and incentivizes the wrong behaviors.

A good manager can get a reasonable subjective sense of individual productivity but won't be able to quantitatively measure it.

Re: Can developer productivity be measured?

#54
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…

Eventually any simply metric like this will become warped because of the effects of both Goodhart's Law, and Campbell's Law.

Re: Can developer productivity be measured?

#56

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…

Two engineers who are not aligned with each other's goals will easily do the work of zero people.

Well said, this point can not be stated enough!

Re: Can developer productivity be measured?

#57
The problem is that we do not have a standard "output unit."

> Productivity: the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.

We can all agree "lines of code" is a shit metric, and we can't say "# of bugs closed," because each will have variable difficulty and value. Programmers employed by a business are in charge of automating repetitive tasks, not performing them (the classic measure of productivity).

I perform UX research on APIs. Here, we standardize the "output unit" and therefore can get a better idea of a developer's productivity. Every developer performs the same task, so we can simply measure time spent.

There will never be an ethical solution to measure developer productivity during the workday; this isn't Ford's assembly line.

Re: Can developer productivity be measured?

#58

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.

Put differently, 80% of his time gave his brain training and practice which likely improved the 20% that made it to market.

Also consider, frustrating though I'm sure that was, he probably still got paid for his effort in the 80%.

Re: Can developer productivity be measured?

#59

The problem is that we do not have a standard "output unit." > Productivity: the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input. We can all agree "lines of code" is a shit metric, and we can't say "# of bugs closed," because each will have variable difficulty and value. Programmers employed by a business are in charge of automating repetitive t…

Even worse, # of bugs closed may be measuring the inverse of what you think you are. See the classic Dilbert cartoon about "writing yourself a new minivan".

Re: Can developer productivity be measured?

#60

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.
Post reply on HN