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

Ask HN: How do you assess developer productivity?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: Ask HN: How do you assess developer productivity?

#11

Post by crate_barre »

Look for track record of deliverables and adjust for human energy. If you see a good track record of things getting done, and then see a drop off, adjust for human energy. Humans can’t be at 100% all the time.

If you measure clinically, then you disrespect what a human being is. You can’t say ‘well you never missed a deadline and now you are, so you must suck or have given up’, this is a really bad thing to do. Empathy is key here.

In other words, you cannot put a number on this, I’m sorry. The eye test is crucial here versus the data.

Re: Ask HN: How do you assess developer productivity?

#12

Post by jstx1 »

breckenedge wrote: post #4

> As an experiment we’ve starred building an app that measures things like PRs and commits for each developer. Ever heard of perverse incentives? This repeats errors made in the early 80s.

Goodhart's law - https://en.wikipedia.org/wiki/Goodhart%27s_law

> When a measure becomes a target, it ceases to be a good measure.

Re: Ask HN: How do you assess developer productivity?

#13

Post by tofukid »

gregjor wrote: post #7

Can you define developer productivity? Before you can measure something you need to have a definition. Measuring PRs and commits is like measuring a writer’s productivity by how many sheets of paper they use. A useful metric might be derived from business value added vs. cost of programming effort, but then how well can the organization measure business value? Or the cost of programmer effort?

Writers do measure productivity by pages written… sure, they may not write a best seller, but there’s a date they start writing and a date the book is published and the book has a word count.

I agree though that lines of code or number of pages doesn’t have much of a relationship to revenue.

Re: Ask HN: How do you assess developer productivity?

#14

Post by high_byte »

jstx1 wrote: post #12
breckenedge wrote: post #4

> As an experiment we’ve starred building an app that measures things like PRs and commits for each developer. Ever heard of perverse incentives? This repeats errors made in the early 80s.

Goodhart's law - https://en.wikipedia.org/wiki/Goodhart%27s_law > When a measure becomes a target, it ceases to be a good measure.

I'm gonna live by that from now on.

Re: Ask HN: How do you assess developer productivity?

#15

Post by quickthrower2 »

tofukid wrote: post #13
gregjor wrote: post #7

Can you define developer productivity? Before you can measure something you need to have a definition. Measuring PRs and commits is like measuring a writer’s productivity by how many sheets of paper they use. A useful metric might be derived from business value added vs. cost of programming effort, but then how well can the organization measure business value? Or the cost of programmer effort?

Writers do measure productivity by pages written… sure, they may not write a best seller, but there’s a date they start writing and a date the book is published and the book has a word count. I agree though that lines of code or number of pages doesn’t have much of a relationship to revenue.

Writing is a bad analogy for programming.

Re: Ask HN: How do you assess developer productivity?

#16

Post by quickthrower2 »

high_byte wrote: post #14
jstx1 wrote: post #12

Earlier quoted context omitted.

Goodhart's law - https://en.wikipedia.org/wiki/Goodhart%27s_law > When a measure becomes a target, it ceases to be a good measure.

I'm gonna live by that from now on.

Then make an OKR that you’ll say it to yourself everyday for 91 days.

Re: Ask HN: How do you assess developer productivity?

#17

Post by giantg2 »

Either you end up counting things that are poor indicators of performance (points, lines of code, commits, etc), or it's completely subjective.

My company basically uses the subjective, using the opinions of 3-4 people. Although some break policy and do things like point counting anyways.

Re: Ask HN: How do you assess developer productivity?

#18

Post by mattbrewsbytes »

I only glance at quantitative things like once a year come review time. Talking with people is a much better way to assess their performance. Usually people are hardest on themselves. Everyone is different, has different life circumstances and performs differently.

In general I think the premise of the question is wrong. It's taking a factory building widgets approach to a creative process. You'd have to have standardized measurable inputs like product requirements that can be worked by anyone on the team. Everyone on the team has to have the same level of experience with the technology used so any learning curve is the same for everyone. Proper standardized estimation needs to be done on every piece of work and then measure the time used to do the work. This is like CMM Level 5 type of utter nonsense, in my opinion.

Also, its more often the case that the inputs (requirements) shift and change as they get worked on which will not be reflected in any quantitative way.

Re: Ask HN: How do you assess developer productivity?

#19

Post by aristofun »

It’s the ultimate mistake people keep making about programmers’ work.

That it’s linear or at least can be approximated with some linear formula, even if multidimensional.

The question itself implies that there’s some linear “productivity” scale where you can put all your developers and see who’s more and who’s less productive.

Because of this fallacy still dominating management minds - we developers can for example hardly justify 2x, 3x salary raise, even though we realize sometimes that our impact and value is as much higher relative to some peers.

The brutal truth is that the contribution of a developer to any complex and big enough project is rarely proportional to any measurable metrics. And barely ever can be reliably connected to such a metrics.

developer A can just sit around few days and invent simple yet scalable decision with just 1 PR, while developer B would be writing thousands of lines of a good looking code.

But this great looking and even well documented code might kill the whole product at some point in near future, even because of some new requirements that nobody could expect (except that developer A, who wasnt promoted for bad “productivity” and quit).

Add to this the fact that often you can’t really know who was good and who was the bad developer - at the moment both had good arguments.

So, my point is that big software products are essentially non linear, dynamic and poorly predictable beasts.

I don’t have ready answers on “how to decide who’s gonna be promoted”.

But i feel the farther you go from trying to “engineer” and “deeplearn” this issue and closer to trusting intuitions of experienced dev leaders, to treating developers as people not machines, considering each project as a unique thing, with unique approaches — the closer you to the truth and to real improvements.

Post reply on HN