Can developer productivity be measured? • Hacker News Board

Re: Can developer productivity be measured?

#121

Post by valenterry » Sat, Dec 12, 2020, 12:37 AM UTC

TameAntelope wrote: post #51

valenterry wrote: post #41

Earlier quoted context omitted.

> 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.

> The value is that the developer doesn’t reasonably have the context

Sorry, that English doesn't make sense to me. The value is that... the developer doesn't have context? How is not having context a value?

Maybe you meant "the reason"? But then that doesn't answer the question what the value is.

Re: Can developer productivity be measured?

#122

Post by chadcmulligan » Sat, Dec 12, 2020, 12:45 AM UTC

This assumes direct managers want productive developers - this is not my experience. The goal of managers is to increase the number of people they manage, and get more money. I have time and again done things fast only to have blocks put in place to slow things down - no one wants the job done easily and go home, where's the money in that. The inability to measure productivity is a direct result of this imho.

Re: Can developer productivity be measured?

#123

Post by bit_logic » Sat, Dec 12, 2020, 1:01 AM UTC

dahart wrote: post #113

In my ~25 years of professional software development, the single biggest factor in productivity for me has been whether I was involved at the start of a project. Knowing the initial design decisions, and being comfortable changing anything , allows me to be orders of magnitude more productive than when I'm diving into existing code designed by someone else. I saw this perhaps most acutely with a company I sold - for…

One of the most powerful benefits from being there since the start is the complete confidence in ripping out and deleting obsolete code later. Even good developers new to the project are afraid to do this, and they should be since it's very risky without the full context.

The natural trajectory for a project is to keep adding features until it collapses from its own weight. Only the long tenure developer can fight this and revitalize a project by removing the useless excess.

Re: Can developer productivity be measured?

#124

Post by kovek » Sat, Dec 12, 2020, 1:30 AM UTC

cratermoon wrote: post #54

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…

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

How do people learn about a lot of “laws”? I know practically none, and it seems so useful to be able to produce them when explaining an idea...

Re: Can developer productivity be measured?

#125

Post by valenterry » Sat, Dec 12, 2020, 1:32 AM UTC

sytse wrote: post #86

jeffbee wrote: post #78

Earlier quoted context omitted.

It seems like a useful aggregate metric, but is it also used to rate individuals? For that purpose, it seems like it would be terrible. What if you have an experienced staff member from whom everyone else constantly seeks advice? That person may be having a positive impact that isn't visible as merge requests.

We try to not go below the level of a group when making productivity assessments. So measure the team instead of the individual. This is indeed to encourage helping each-other out as you noted.

> We try

And what do you do in the end?

Re: Can developer productivity be measured?

#126

Post by knaq » Sat, Dec 12, 2020, 2:06 AM UTC

Sure, it's easy. Count how many lines of code they write per day. Likewise, aeronautical engineering productivity can be measured by counting kilograms of mass added per day.

The real underperformers go negative.

Re: Can developer productivity be measured?

#127

Post by fizx » Sat, Dec 12, 2020, 2:10 AM UTC

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…

I assume you mean expensive mistakes! Making cheap mistakes is a great way to learn!

Re: Can developer productivity be measured?

#128

Post by sdesol » Sat, Dec 12, 2020, 2:12 AM UTC

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…

I'm currently building models around high functioning software developers/projects and what I've noticed is, churn can swing quite a bit. Take the following for example:

https://imgur.com/Yb8WvJY

Over 150 days, this developer's churn really fluctuates and that's because they work on different things, that requires different amounts of code. And if you look at the following:

https://imgur.com/oNmsMSV

you can see they still commit regularly, but as the Reviewability section shows, their changes are mainly small ones, which sort of aligns with what Sid (sytse) mentioned, which is mainly focusing on small changes.

If you look at the bigger picture:

https://imgur.com/vmiOtgU

https://imgur.com/5vf3kWj

The churn for the project microsoft/vscode fluctuates quite a bit as well.

Based on what I've learned so far, you really need a good baseline (that can vary greatly from one developer to another) to be able to determine if somebody is more/less productive.

Re: Can developer productivity be measured?

#129

Post by TameAntelope » Sat, Dec 12, 2020, 2:31 AM UTC

valenterry wrote: post #121

TameAntelope wrote: post #51

Earlier quoted context omitted.

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.

> The value is that the developer doesn’t reasonably have the context Sorry, that English doesn't make sense to me. The value is that... the developer doesn't have context? How is not having context a value? Maybe you meant "the reason"? But then that doesn't answer the question what the value is.

The person I replied to asked what the business value was, so I explained that the [business] value comes from having a dedicated person who understands the context in which the issue is being worked.

Re: Can developer productivity be measured?

#130

Post by voxl » Sat, Dec 12, 2020, 2:33 AM UTC

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…

I have never had the opportunity to try this method but after much theory crafting and many useless pointing meetings and much statistical investigation with negative correlation between "complexity" and "time to completion" I can only think that this is the correct way to get velocity.