What is developer productivity and how to measure it? • Hacker News Board

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

#81

Post by tonyedgecombe » Wed, Mar 02, 2022, 12:36 PM UTC

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…

There is plenty of research that show extrinsic rewards don't really work that well, especially for intellectual endeavours.

On top of that you have the problem that now your developers will follow the set objectives to the letter even if it transpires that something else was required.

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

#82

Post by tonyedgecombe » Wed, Mar 02, 2022, 12:45 PM UTC

thenerdhead wrote: post #35

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

>An outcome is finally merging an unsustainable PR that has sat for a month.

Ultimately the desired outcome is money arriving in the bank. Which is even less fathomable.

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

#83

Post by tonyedgecombe » Wed, Mar 02, 2022, 12:53 PM UTC

anamax wrote: post #59

ok_dad wrote: post #43

> Measuring developer outputs can be detrimental because there are not enough data points to understand if the unproductiveness was caused by the developer himself, or by his surroundings/company . How about just doing your best as an organization and as a people manager to make your developers happy and fulfilled ? That increases productivity and motivation to succeed more than anything, IMO. Give great pay raises r…

> Management always wants to think that they are right in every decision and the employees are the ones who are unproductive, but after decades of working for "the man" in about 10 different industries in different positions/careers, I have found the fault lies with management 80 to 90 percent of the time due to some leadership failure or combination of failures. Getting crap reviews/evaluations because a project fai…

That's all well and good but if you accept the premise that 80 to 90 percent of management is failing then you need luck on your side to avoid ending up in the same situation again.

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

#84

Post by thenerdhead » Wed, Mar 02, 2022, 1:42 PM UTC

passivate wrote: post #74

thenerdhead wrote: post #71

Earlier quoted context omitted.

We measure happiness and various sentiments towards these areas like knowledge transfer, documentation, ci/cd reliability, pr velocity, etc. The f1 pit crew analogy refers to how certain teams realized that measuring KPIs too religiously meant the vary difference of performance when it mattered. Similar to other sports where coaching actually matters and these metrics are rather useless unless there’s a coaching role…

>We measure happiness and various sentiments towards these areas like knowledge transfer, documentation, ci/cd reliability, pr velocity, etc. I see, so you guys don't measure anything specific that is actionable? Did you face any challenges dealing with non-performers or under-performers dragging the team down?

Yes. Those people tend to also be happiest with each of these areas and have coaching plans with their managers given they are also early in career. Unhappiest are the senior and principal talent, but not by much more.

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

#85

Post by astrobe_ » Wed, Mar 02, 2022, 6:09 PM UTC

jbay808 wrote: post #69

astrobe_ wrote: post #47

Earlier quoted context omitted.

Because I am talking about programmers, not about mercenary-developers.

Then what change in behaviour were you expecting your incentive scheme to result in?

The "scheme" a) draws from gamification b) prevents the sometimes hostile reception of the use of metrics c) reinforces the feedback loop. Positive perception leads to positive behavior.

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

#86

Post by passivate » Wed, Mar 02, 2022, 8:33 PM UTC

closeparen wrote: post #76

passivate wrote: post #66

Earlier quoted context omitted.

Agreed, we need both quantifiable metrics, and also a human brain to interpret them with subjectivity, context and compassion. I see many people wanting to take writing code into the liberal arts domain, but I am of the opinion that it may be more useful if we can overlap it with the engineering domain. IMHO the goal should be to repeatedly churn out high-quality bug-free code, and to create an objective process meth…

The part where the code needs to execute correctly is engineering domain. But lots of bad code executes correctly. "Programs must to be written for people to read, only incidentally for machines to execute." Writing things for people to read is unavoidably an arts discipline.

>Writing things for people to read is unavoidably an arts discipline.

I understand what you mean, but I'd have to disagree with that. I've been working on a very large engineering project with a large-ish team (~50 members) for over two years. All of our communication is via an established methodology of engineering diagrams, design documents, position papers, etc all of which are in a structured format that follows common rules/regulations/conventions.

As a result, all the companies we work with for e.g. understand our P&ID diagrams, electrical schematics, mechanical design docs, system layout diagrams, etc. There is no reason why such a methodology can't be brought to code. I don't view code as anything special - having now worked on on both sides. I think there really is a lot of value in the engineering methodologies that can be adapted and applied to the software world.

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

#87

Post by passivate » Wed, Mar 02, 2022, 8:34 PM UTC

thenerdhead wrote: post #84

passivate wrote: post #74

Earlier quoted context omitted.

>We measure happiness and various sentiments towards these areas like knowledge transfer, documentation, ci/cd reliability, pr velocity, etc. I see, so you guys don't measure anything specific that is actionable? Did you face any challenges dealing with non-performers or under-performers dragging the team down?

Yes. Those people tend to also be happiest with each of these areas and have coaching plans with their managers given they are also early in career. Unhappiest are the senior and principal talent, but not by much more.

Okay, interesting. If you don't mind saying, what is the size of your team?

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

#88

Post by thenerdhead » Wed, Mar 02, 2022, 8:48 PM UTC

passivate wrote: post #87

thenerdhead wrote: post #84

Earlier quoted context omitted.

Yes. Those people tend to also be happiest with each of these areas and have coaching plans with their managers given they are also early in career. Unhappiest are the senior and principal talent, but not by much more.

Okay, interesting. If you don't mind saying, what is the size of your team?

30+ ICs between two major OSS codebases.

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

#89

Post by closeparen » Thu, Mar 03, 2022, 3:36 AM UTC

passivate wrote: post #86

closeparen wrote: post #76

Earlier quoted context omitted.

The part where the code needs to execute correctly is engineering domain. But lots of bad code executes correctly. "Programs must to be written for people to read, only incidentally for machines to execute." Writing things for people to read is unavoidably an arts discipline.

>Writing things for people to read is unavoidably an arts discipline. I understand what you mean, but I'd have to disagree with that. I've been working on a very large engineering project with a large-ish team (~50 members) for over two years. All of our communication is via an established methodology of engineering diagrams, design documents, position papers, etc all of which are in a structured format that follows…

Do your diagrams, design docs, and position papers not vary in the clarity of their presentation or in the wisdom/simplicity/fitness-for-purpose of the ideas they convey?

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

#90

Post by passivate » Thu, Mar 03, 2022, 5:09 AM UTC

closeparen wrote: post #89

passivate wrote: post #86

Earlier quoted context omitted.

>Writing things for people to read is unavoidably an arts discipline. I understand what you mean, but I'd have to disagree with that. I've been working on a very large engineering project with a large-ish team (~50 members) for over two years. All of our communication is via an established methodology of engineering diagrams, design documents, position papers, etc all of which are in a structured format that follows…

Do your diagrams, design docs, and position papers not vary in the clarity of their presentation or in the wisdom/simplicity/fitness-for-purpose of the ideas they convey?

Indeed, they vary. The larger point is we still get a lot accomplished/communicated and done because of a common underlying methodology. I don't have an answer for what that means when adapted to the software field. Its going to be a soup of many things - coding guidelines, BDD, TDD, modular programming, etc, etc. I'm sure there are brains far bigger than mine already working on this, its not really an original idea in that sense.