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

Worst Software Metrics

gitclear.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Worst Software Metrics

#41

Post by jknoepfler »

In order to add value to a dev team as a manager, one must have an intimate understanding of the work developers do. There isn't any value in abstracting away from that work when evaluating the contribution of team members.

"Context, action, outcome" is a sufficiently standardized formalism for evaluating performance (assuming outcomes are measured in terms of business value). Accurately reporting context, action, outcome requires understanding both what devs do, why they do it, and how it ultimately produces business value. There's no shortcut. If your management can't meaningfully do that because they are non technical or managing too many people, or whatever, then they are actively harming your team and should be removed with prejudice.

There is no reasonable way to conclude that devs can be effectively measured with garbage stats. Even suggesting it seriously indicates incompetence or laziness.

Re: Worst Software Metrics

#42

Post by overgard »

gtirloni wrote: post #39
shakezula wrote: post #32

At a previous job of mine, they implemented a "personal improvement plan" for employees who were below management's "desired productivity". There was no warning, no heads up that they would be measuring our GitHub accounts, and it had absolutely no context of what each person had been working on. These reviews came after a 360 peer review, and absolutely blindsided the team. Several of my coworkers left early for the…

I'm sorry this experience left you scared of metrics but it doesn't mean they are bad, just that people need to know how to use them. I've had this exact conversation before and the extremism of "metrics are always weapons" was a contributing factor for me to leave a, say, less metrics-inclined workplace. Just saying there has to be balance.

I've been a professional software developer for twelve years, and while I'm trying to keep an open mind, I have yet to see any useful metrics for what we do. Like, useful AT ALL. I can think of zero numerical metrics that can accurately tell you what's going on with a team. Number of commits, burndown charts, velocity, issues closed/created, whatever, they're all simultaneously easily game-able and also create bad incentives.

And by the way this isn't sour grapes, metrics have almost always made me look good. One job I left, I had so many more commits than the next person that it took them two years after I left to catch up to me. And yet I'm absolutely certain I was not the most useful person on that team. The most useful person was the guy that was writing the extremely sophisticated modelling kernel, and if you only looked at the metrics he probably looked borderline useless, but in actual terms he was by far the most valuable and important person on our team.

What scares programmers is, everyone on our team knew that, and any sort of manager with programming experience probably knows that, but you know that those stats are going to eventually float up to someone who doesn't know that the numbers are bogus. (After all, they wouldn't be tracking these numbers if they knew how bad they are). So decisions do get made from these numbers, even when people promise they wont.

Re: Worst Software Metrics

#43

Post by perl4ever »

x3n0ph3n3 wrote: post #10
toolslive wrote: post #2

Actually, LOC isn't that bad. Studies have shown - that complexity metrics are highly correlated with LOC. - people can produce & maintain software at about 10 LOC/h. This seems to be a constant of the mind. It means you're better off doing 10 lines of python than 10 lines of ASM as the 10 lines of python will do a lot more. Both facts are discussed at length in "Making Software" (Oram, Wilson)

> people can produce & maintain software at about 10 LOC/h. That is shocking and horrifying if that's the norm for software development.

I think that people who claim to write many lines of code per hour just don't count small amounts of time lost and don't realize it adds up or feel it should be exempt from counting. It's like the calories in broken cookies, or the ten minutes it takes to get out the door when you only spent a few seconds grabbing a few things.

One thing that I think can give you perspective is if you experience a job where you account for your time like lawyers do, in 6 or 15 minute increments. It's surprisingly hard to get your billable time over 50%, assuming you're honest about it.

Re: Worst Software Metrics

#44

Post by perl4ever »

commandlinefan wrote: post #5

> The longest has taken two weeks and is still ongoing. Even worse, the typical braindead “solution” to this problem is to insist that everything be broken up into chunks of a few hours or less each before work can begin. The end result is “if it can’t be done in a couple of hours, it isn’t worth doing”.

It seems like I have read where "esteemed members of the community" advocate this, at least to enable estimation. Joel-on-software, maybe?

Re: Worst Software Metrics

#46

Post by overgard »

ilaksh wrote: post #15

I have a solution to these metric gotchas. Don't install Jira at all and then you won't be tempted by any of them. Better yet, don't hire a manager at all. Instead get one or two senior devs and include them in some business discussions and incentives.

gasp include senior devs in a conversation about development? Blasphemy. At so many places it's like there's some unwritten law that you can't include developers in any sort of business conversation, you need to hire a project manager as a go-between in order to badly translate things between business and development so neither side actually knows what's going on.

Re: Worst Software Metrics

#47

Post by overgard »

forgotmylogin2 wrote: post #27

Is this operating under the assumption that there is no code review? With code review, lines of code and commit count become much harder to game. If you try to submit changes with unnecessary whitespace, unnecessary code constructs, or incomplete code, your reviewer will see it and tell you to fix it. Ultimately, trying to increase your lines of code or commit count will come back to haunt you as you spend much more…

It's still super-easy to game. Just prioritize all the low-hanging fruit. Got some tickets for increasing the font size or replacing the copy in the privacy policy? Why not do those instead of working on the important but hard to debug/estimate problem of some database transactions being slow, but only sometimes?

Re: Worst Software Metrics

#48

Post by vageli »

Is the measure of an architect the number of lines in a blueprint? Is the measure of a craftsman the number of finished goods produced? It seems to me that different projects in the same domain should use different attributes to evaluate success. Why do we attempt to use uniform measures across-the-board? Is it lazy management or does delving deep into project-specific metrics make it hard for large enterprises to compare employees in similar functions? Or something else?

Re: Worst Software Metrics

#49

Post by aryamaan »

overgard wrote: post #42
gtirloni wrote: post #39

Earlier quoted context omitted.

I'm sorry this experience left you scared of metrics but it doesn't mean they are bad, just that people need to know how to use them. I've had this exact conversation before and the extremism of "metrics are always weapons" was a contributing factor for me to leave a, say, less metrics-inclined workplace. Just saying there has to be balance.

I've been a professional software developer for twelve years, and while I'm trying to keep an open mind, I have yet to see any useful metrics for what we do. Like, useful AT ALL. I can think of zero numerical metrics that can accurately tell you what's going on with a team. Number of commits, burndown charts, velocity, issues closed/created, whatever, they're all simultaneously easily game-able and also create bad in…

That's my company.

Re: Worst Software Metrics

#50

Post by mnowicki »

ben509 wrote: post #29
wbharding wrote: post #12

Earlier quoted context omitted.

While I recognize the prevalence of Goodhart's law among smart thinkers, it fails to meet my "important truth" threshold because it's not hard to find counterexamples: * In baseball, batting average and OPS are metrics that are richly rewarded. Players who successfully strive to improve their average/OPS will help their team win more, and they'll get richer for it. * In finance, ROI is rewarded, and investors whose R…

I think your counterexamples reveal why those metrics work: * In baseball, batting average and OPS require you to compete against other teams. * In finance, ROI is tested in the marketplace. * In sales, conversions require you to convince a skeptical customer. The software metrics are all things we have fairly direct control over. Maybe that suggests an amendment to Godhart's law: > When a measure that is controlled…

I was just writing a post that said the same exact thing with about 12 times as many words. Good thing I read your comment before I wasted another 20 minutes writing the other half of my response
Post reply on HN