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

What is developer productivity and how to measure it?

axolo.co

Post reply on HN
Print view View original

31–40 of 91 posts

Re: What is developer productivity and how to measure it?

#31

Post by robocat »

arthurcoudouy wrote: post #15
astrobe_ wrote: post #7

Funny. I read a book a long time ago about developer productivity. They started with saying: "measuring productivity witk KLoCs is terribad". And later on: but we only have that, so let's use it anyway. "Stopped reading there". And here in 2022 it's exactly The Same Thing: > Measuring developer outputs can be detrimental And then: > Design and coding: The number of design papers and specs, work items, pull requests,…

I'm personally not a huge fan of collecting quantitative data to evaluate engineering productivity. The context of such metrics is usually more important that the data itself, meaning using some discrepancies in your results to identify business needs or issues. When I work with quantitative data, I try to find pattern rather than analyzing the data iself (why do pull requests last longer on Monday afternoon? do we h…

I suggest that in every comment, you add “author here” or similar to make that very clear, because it isn’t always very obvious from your comments.

Re: What is developer productivity and how to measure it?

#32

Post by lgleason »

More lines of code = more liability. Also more commits, frequency of commits etc. does not equate to more productivity. In fact in some instances you actually are introducing more liability into a codebase doing that. The flaw with most of these metrics of "productivity" is that they inherently are saying that coding is analogous to a factory worker building something when in reality it is analogous to someone designing the things the factory worker has to assemble.

While I'm not a fan of subjectivity in ratings, the challenge is that it is very difficult, and I would argue, virtually impossible to do it objectively. So what happens instead is that when metrics are used to evaluate engineers, the smart ones figure out how to game them. Does that make them, or the team more productive? Nope. Can that have un-intended consequences that actually make the code less stable, and decrease productivity. Yup!

But if you're going to go with these measurements you might as well go big. Throw out anything related to Agile, require estimates that are accurate within 15 minutes and severely punish engineers for not getting estimates right. Might as well also add in heavy documentation requirements too. After all, this rigorous measurement etc. has all worked so well in the past .

Re: What is developer productivity and how to measure it?

#33

Post by jgust »

lacker wrote: post #3

I don't agree with most of the advice in this article but rather than complain let me suggest an alternative. As a line manager, with software engineers reporting directly to you, you should be able to use your personal judgment to understand the productivity of your software engineers. Don't measure it with acronyms, with metrics like the number of commits, or by paying attention to how many hours a week people are…

There's an entire class of products I'll name "internal platform tools" whose primary objective is to improve the developer experience with the intent of having the side effect of increased developer productivity by making it easier & more enjoyable to build things within a company. The teams working on these tools need to understand how their products perform the same as a team building some widget for a "paying" customer.

Without some quantifiable metric, how do these teams know if their products are getting better or worse? The discussion always goes to measuring developer happiness & developer productivity because we want with some degree of confidence to be improving or at least maintaining these metrics.

Re: What is developer productivity and how to measure it?

#34

Post by lgleason »

whoomp12342 wrote: post #17

we(as an inudstry) measure it by claiming we do scrum but in actually just create pomp and circumstance and just do what we would do anyways. It gives us a number, we dont care if its accurate or effective

I have yet to see engineers that are even close to being accurate with estimates because they are in essence inventing something new with a bunch of unknowns. Put another way, there are two types of engineers. Those who are bad at estimating who readily admit to it and those who lie about their skills at estimation.

Re: What is developer productivity and how to measure it?

#35

Post by thenerdhead »

> Each organization can set a wide range of metrics to follow every week, such as:

> Number of commits.

> Average commit size.

> Frequency of code reviews.

> Number of code reviews.

> Time to review.

> and so on...

No. This has been tried many times and companies think this is how you measure productivity, but it is not even sustainable. Developer productivity is not about moving the needle, it is about outcomes, and not outputs.

An outcome is finally merging an unsustainable PR that has sat for a month. It is not how many comments, reviews, meetings, or commits needed to get to the outcome.

The only people I know who want to implement these terrible measurements are the type of people who have ambitions as large as Mount Everest but die on the decline back down. The real goal is to be more like a f1 pit crew where you leave out the metrics and end up performing better than if you measured them.

Re: What is developer productivity and how to measure it?

#36

Post by giantg2 »

lacker wrote: post #3

I don't agree with most of the advice in this article but rather than complain let me suggest an alternative. As a line manager, with software engineers reporting directly to you, you should be able to use your personal judgment to understand the productivity of your software engineers. Don't measure it with acronyms, with metrics like the number of commits, or by paying attention to how many hours a week people are…

We just need to be careful that this unquantifiable, subjective rating doesn't include biases.

Re: What is developer productivity and how to measure it?

#37

Post by jbay808 »

astrobe_ wrote: post #25
astrobe_ wrote: post #7

Funny. I read a book a long time ago about developer productivity. They started with saying: "measuring productivity witk KLoCs is terribad". And later on: but we only have that, so let's use it anyway. "Stopped reading there". And here in 2022 it's exactly The Same Thing: > Measuring developer outputs can be detrimental And then: > Design and coding: The number of design papers and specs, work items, pull requests,…

One more thing: "put your money where your mouth is". Bug bounties work, why wouldn't "feature bounties" also work? You say you want those features, preferably bug-free, for this deadline. And there's $5K for the team if the objectives are met. Then, your metrics problem boils down to how to impartially measure customer satisfaction, or how well the objectives are met (in some contexts, bugs are unavoidable etc.). Me…

It's very hard to align an explicit incentive scheme with the outcome that you actually want.

In this case, you'll get your features, but they very likely won't be bug-free. They'll probably be quite slow and fragile. They might not scale. They might not be well thought-out. They might break backwards compatibility, or break other features that your customers are already using.

In other words, why wouldn't a developer borrow limitless technical debt in order to claim the bounty as fast as possible and move on to their next bounty?

Re: What is developer productivity and how to measure it?

#38

Post by qbasic_forever »

giantg2 wrote: post #36
lacker wrote: post #3

I don't agree with most of the advice in this article but rather than complain let me suggest an alternative. As a line manager, with software engineers reporting directly to you, you should be able to use your personal judgment to understand the productivity of your software engineers. Don't measure it with acronyms, with metrics like the number of commits, or by paying attention to how many hours a week people are…

We just need to be careful that this unquantifiable, subjective rating doesn't include biases.

Exactly, I don't know what the answer is (probably a combo of subjective and objective measures, along with a healthy dose of independent oversight for both) but relying completely on 'gut feeling' is an express train to unconscious bias land.

In reality I think someone who only looks at team members who are "doing the most" is really just measuring who is talking about their work the most. You need some kind of objective measures like features shipped, assigned bugs resolved, etc.

Re: What is developer productivity and how to measure it?

#40

Post by arthurcoudouy »

robocat wrote: post #31
arthurcoudouy wrote: post #15

Earlier quoted context omitted.

I'm personally not a huge fan of collecting quantitative data to evaluate engineering productivity. The context of such metrics is usually more important that the data itself, meaning using some discrepancies in your results to identify business needs or issues. When I work with quantitative data, I try to find pattern rather than analyzing the data iself (why do pull requests last longer on Monday afternoon? do we h…

I suggest that in every comment, you add “author here” or similar to make that very clear, because it isn’t always very obvious from your comments.

Thank you for the suggestion! Will do
Post reply on HN