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

31–40 of 68 posts

Re: Worst Software Metrics

#31

Post by majormajor »

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…

The sort of code review that ends up at "you can't land this until it looks exactly like the code I'd write" can be its own sort of hell...

Re: Worst Software Metrics

#32

Post by shakezula »

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 day and didn't come in for the rest of the week. I got calls all day from various people asking what happened in my 1:1, what was said, etc...

I wish I could show management how negatively and immediately that move affected the culture & mood of engineering at that company. It was an overnight change, and going forward it basically killed all trust in management. I stayed around for a little bit longer, but I should have quit the second they started those measurements.

It absolutely murdered the confidence of our junior devs. Of the senior engineers who were put on it, none of them really had any idea what they were doing wrong or how to improve, as no feedback was given about any of that, just that they weren't enough. Some of our seniors had 15+ years of experience in software and were industry experts, but it didn't matter: They hadn't been hitting the number of commits and pull requests and tickets per week that management insisted on.

When management was confronted about it, they admitted that code metrics aren't a good measurement of productivity, but then insisted that they "needed something".

It turns out, they only used code metrics as a bludgeon to get rid of the employees they wanted gone, and since then that's all I've been able to see code metrics as. They're a battering weapon used to give HR a performance reason to justify firing you.

Re: Worst Software Metrics

#33

Post by jschwartzi »

raxxorrax wrote: post #16
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)

But if you measure it to determine performance, you are not paying developers to create solutions, you are paying them to create LOC. That could have quite a negative influence. If we could channel energy from creating performance metrics into a form of reporting that continually narrows down the problems that need solving, productivity would be served better. Otherwise we could probably use keystrokes per second jus…

I actually think it's important for LOC to be considered as a key performance metric, because it makes it much easier for me to outsource my work to a team of these delightful little fellows:

https://en.wikipedia.org/wiki/Drinking_bird

Re: Worst Software Metrics

#34

Post by chiefalchemist »

wbharding wrote: post #12
Kinrany wrote: post #7

Earlier quoted context omitted.

And at the same time you still can't use LoC to measure productivity and reward for it because of the Goodhart's law.

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…

Maybe. But are you going to deduct for bugs? Or other flaws due to the metric not being "done right, and complete"?

Re: Worst Software Metrics

#36

Post by notmyfuture »

I’m a manager of ~25 developers (who report through a few leads). I also come from a dev background. IMO metrics are dangerous, but can also be useful. Often I find basic code metrics useful as smell tests, but would never use them alone, wouldn’t set them as goals, and wouldn’t use them alone to rank performance in a team.

If someone has a very low number of commits relative to others on their team, I’ll investigate deeper - review a few Pull Requests, check if they’re working on something outside source control etc. sometimes I find problems, other times not.

I’m curious what people think of this approach?

Re: Worst Software Metrics

#37

Post by _Marak_ »

notmyfuture wrote: post #36

I’m a manager of ~25 developers (who report through a few leads). I also come from a dev background. IMO metrics are dangerous, but can also be useful. Often I find basic code metrics useful as smell tests, but would never use them alone, wouldn’t set them as goals, and wouldn’t use them alone to rank performance in a team. If someone has a very low number of commits relative to others on their team, I’ll investigate…

I would think this is a common approach. I use the same approach. Scales up to hundreds of developers.

I do generally try to enforce the goal that on any working day there should be at least one commit from the developer. If I notice a developer is consistently missing this metric it usually indicates trouble in the project they are working on or that the developer is just not delivering enough.

Re: Worst Software Metrics

#38

Post by coldcode »

TuringNYC wrote: post #23
sebastianconcpt wrote: post #18

Yep! Considering that the metrics above are still considered viable at the dawn of 2020 proves how much opportunity still remains for managers to improve the measurement -> incentives -> long-term outcomes achieved by their team. To their credit, the instinct that leads managers to utilize these metrics is sound. They know that the best businesses make their best decisions using data. But so much depends upon whether…

>> The metric would consider "issues resolved," but only after normalizing for implementation complexity, so developers that work in front-end systems don't take the lion's share of credit after resolving a myriad of tiny tickets. Only if you are not being rewarded for solving your own bugs. Otherwise, I've seen this go horribly awry. I was at a Big 5 consulting company where one project was big on "how well you mana…

This is known as the Cobra Effect.

I worked at a healthcare company where the chief architect was considered a genius by upper management because he would dive in and "save" production; in reality he was the cause of all the bugs that broke it but he did not allow anyone to fix the problems.

Re: Worst Software Metrics

#39

Post by gtirloni »

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.

Re: Worst Software Metrics

#40

Post by overgard »

Ugh the "velocity" one really hits home. A couple of jobs ago one of our project managers was constantly showing burn down charts (which, of course, never burned down); along with our "velocity". The funny thing is, because we were doing t-shirt-size/fibonacci, our velocity numbers varied so wildly that it was essentially a random number generator. Then we were required fit all our stories within a "budget" of our "average" velocity.. What are you supposed to do with the average of a random number between 0 and 200? Apparently a lot, because these insane numbers that had no actual tie to reality were used to determine how much we were allowed to "commit" to. Never mind that some months we'd finish 50 story points and some months 250 (because, again, the numbers were a fiction); we were always trying to fit things into 90 story points.

Luckily all this useless theater only took up an entire day every two weeks. If you assume everyone on the team was making about $50 an hour, and it was about 6-8 people in attendance to these things, then it came out that this very dumb "estimation" process took 6 people * $50/hr * 6 hours... so about 1800 dollars. (Not including the project managers salary, which given that he drove around a very fancy luxury car, was probably a lot more than the rest of us).

And people wonder why I don't take scrum seriously.

Post reply on HN