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

41–50 of 91 posts

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

#41

Post by qbasic_forever »

blurker wrote: post #4
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…

I too have come to think that no simple metrics will ever replace the need for a competent manager who can use intangible, subjective context to evaluate their team. I think that even if you get some metrics that work well initially, the system will change such that the metric becomes the goal and the metrics then become much less effective.

You still have a goal that people are optimizing for though--how to increase that intangible, subjective measure known only to the manager. It leads to people optimizing for talking about the stuff they do more, showcasing their accomplishments, and in bad extremes brown-nosing, infighting and sabotage of others work. Whether any of those behaviors lead to a better product or outcome for the company is something to strongly consider.

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

#42

Post by Clubber »

lgleason wrote: post #34
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.

It really depends on how you define bad at estimating. I can tell if something will take a few hours or a few days pretty reliably, but not down to the second. The trick is to include all the friction into the estimate (test, deploy, potential collateral damage, random pings from biz or devs, etc) then add 30% for oops factor. It's much better to be early and overestimate than be late, particularly when there are dependencies on your completing on time. The more you know a codebase, the better at estimates you are of course.

This all falls apart without a good tight spec. If the spec is loosy-goosy, then forgetaboutit.

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

#43

Post by ok_dad »

> 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 regularly, give a ton of time off, get rid of people managers who are jerks, etc. If your company has goals, and your developers aren't producing code to meet the goals, your goals are probably too high, you have too few developers, or your developers aren't motivated to complete the goals because they are being treated like shit or don't agree with the goals.

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. The problem is poor leadership and lack of motivation, no doubt in my mind. I've also led large groups of people (in the military) and by far the best thing I could do for them was make their personal and work lives better by not getting in the way and by not acting like a dickhead. Adding metrics to things just caused more useless work for me. You can't force change in a system via metrics, the only place where measurement changes outcome is in quantum physics.

I hate to go on a "capitalism vs. communism" type rant, but the best places I have ever worked, with the best "productivity", have been flat orgs where the developers and other employees are included in the decision making and the management and execs are open and caring and don't try to put profits and the business above the personnel. When everyone shared the success or failure of the company on equal terms, we could all get things done that were unthinkable.

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

#44

Post by cco »

jgust wrote: post #33
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" cu…

Generally you find the problems in your developer experience, and use those as your metrics. Maybe it takes three PRs and an hour and fifteen minutes to deploy to prod, lower number of PRs and minutes to deploy would be your metrics.

Or maybe to introduce a new endpoint in your API takes X amount of boilerplate lines, Y files, etc and you post mortem new endpoints after your change to ensure that number is dropping.

Talk to people, find out what their problems are, quantify the problem, measure.

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

#45

Post by marcinzm »

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.

Everything including "objective" metrics includes bias. And that's before you take into account people outright gaming metrics (objective or subjective).

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

#46

Post by marcinzm »

jbay808 wrote: post #37
astrobe_ wrote: post #25

Earlier quoted context omitted.

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

Especially since the developer will likely be at a new company or team in 1-2 years.

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

#47

Post by astrobe_ »

jbay808 wrote: post #37
astrobe_ wrote: post #25

Earlier quoted context omitted.

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

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

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

#48

Post by closeparen »

jgust wrote: post #33
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" cu…

Inefficiencies in the developer experience show up as frustrations for developers. Developers are very happy to tell you what frustrates them and how badly.

Often what frustrates people is a latency, which is something you can measure and track. Other times it is an ugliness, surprising footgun, or lack of conceptual integrity - these are fundamentally human experiences, and subjective assessment is the only way.

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

#49

Post by commandlinefan »

Clubber wrote: post #42
lgleason wrote: post #34

Earlier quoted context omitted.

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.

It really depends on how you define bad at estimating. I can tell if something will take a few hours or a few days pretty reliably, but not down to the second. The trick is to include all the friction into the estimate (test, deploy, potential collateral damage, random pings from biz or devs, etc) then add 30% for oops factor. It's much better to be early and overestimate than be late, particularly when there are dep…

> This all falls apart without a good tight spec

Maybe I've had 30 years of bad luck, but I've never seen a "good tight spec" since I started programming professionally in 1992. Most of the time there's no "spec" at all.

Even if you do manage to get the estimate-demanders to back off until the spec is good and tight, you're just moving the problem upstream - they'll just want an estimate on how long it will take to get the spec right.

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

#50

Post by RangerScience »

CraigJPerry wrote: post #14

I’m getting a chuckle at the hubris in the comments so far. Possibly the world expert at this point (Dr Nicole Forsgren) in this exact topic comes up with a framework based on the best of what she knows from years of studying this and refining her approach. Random HN commenter: ahh just measure time to commit. Random HN commenter: biases are cool, so just use personal judgement.

Article is confusing because it presents SPACE with proper "header" styling opening the section, but then rolls right into DORA as if it's another paragraphs instead of an entirely different section.

(you're still not wrong tho haha)

Post reply on HN