21–30 of 91 posts
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.
Earlier quoted context omitted.
Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster. I think that qualitative metrics like satisfaction and collaboration could be helpful, especially when combined with traditional me…
> Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster. I think this depends on how strongly leadership/management tries to use this metric to change behavior, but in a company like min…
Absolutely. It’s the old descriptive vs normative saw. We should be very interested in measuring how productive we are. But how do we really know how productive we should be?
I think trying to answer that is hard to impossible for a developer, because you can always automate or abstract further, but the cost to do so marginally increases and you probably won’t know the full cost until it’s already realized, at which point, requirement and prediction are obviated.
I know I’ve had my fair share of negative experiences with a scrum team that wanted ever faster velocity and used burndown charts as a stick with no carrot in sight.
Earlier quoted context omitted.
Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster. I think that qualitative metrics like satisfaction and collaboration could be helpful, especially when combined with traditional me…
> Using a metric like mean time to code change could incentivize brute forcing work. Developers who are aware of the metric may work unsustainable hours and that could lead to burnout. Also, they may try to cut corners on tests, reviews or documentation in order to ship more things faster. I think this depends on how strongly leadership/management tries to use this metric to change behavior, but in a company like min…
I could see how a satisfaction metric would counterbalance a work output metric. The team will probably feel less satisfied if they know that corners are cut or if they are having to work unsustainably.
Fix a bug, Add feature set Do something new.
My epithet for one programmer was "He writes a lot of code"
Extra code makes it harder for the next guy to figure out what's going on, and has more space for bugs.
But that came from a "productive" developer and that code can tie down a dozen maintainers in dozens of customer sites.
The productivity is job creation for a bunch of folks whose main ambition is finding a job where they don't have to work with crap code.
I've done a number of projects where I got rid of multiples of code compared what I put in.
The best example was where I replaced a subroutine with a single character constant.
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,…
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.).
Metrics can still be important to help the team identify their problems (or rather, confirm that their intuitions about the problem). It's an optimization problem: measure first, then do something about the actual bottlenecks.
That said, some programmers are such nerds that more money is not the highest motivation. One can use some creativity here.
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.
I cannot find anyone suggesting using time to commit as a metric in the existing comments.
> The DORA (DevOps Research and Assessment) framework introduced some metrics to track team flow, such as deployment frequency, which measures how frequently an organization successfully releases to production, and lead time for changes, which measures how long it takes a commit to reach production. If you're interested in the DORA framework, we published a dedicated article on How to implement the Four Key Accelerate DevOps Metrics.
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.
I cannot find anyone suggesting using time to commit as a metric in the existing comments.
Measuring developer productivity is like observing quantum state, the act of measuring it generally fucks it all up. Rather than task the developers with all manner of bureaucratic Agile bullshit like tracking hours, arguing about story points, submitting to kindergarten-style daily stand-ups, velocity tracking, retros, etc; I would suggest a different tact. How about measuring developer productivity by observing if…
This is a much more entertaining version of Goodhart's law [1]
> because productivity and contentment are linked, it's feasible that satisfaction can operate as a leading indicator of productivity; a drop in satisfaction and engagement could foreshadow impending burnout and lower output. Great review of the hazards involved in quantifying developer productivity - the correlation above has been true everywhere I’ve ever worked. If the company you’re working for: - is not investin…
Well put! > your life and happiness Also remember that these things are why you're here in the first place, and not to be the best Level 4 SWE Management Trainee in the trans-western division this quarter. It's only healthy to maintain perspective. It can hurt in the short run sometimes, but there's only misery if you don't keep it.