Worst Software Metrics
gitclear.com
Worst Software Metrics
1–10 of 68 posts
Re: Worst Software Metrics
#2Actually, 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.
Both facts are discussed at length in "Making Software" (Oram, Wilson)
Re: Worst Software Metrics
#3Actually, 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)
You're discussing it as a negative metric/limiting factor/base constant type of thing, but that's not the context in the article:
>Thus, the "most valuable developer" as measured by LoC tends to be whoever is adding the most CSS, whitespace, and third-party libraries.
It's still as terrible as ever to positively correlate developer productivity/quality/skill with LOC.
Re: Worst Software Metrics
#4Does anybody know of a study documenting that measuring and reporting software code quality metrics actually improve the project/product team's ability to deliver?
So far I've only found studies documenting that measuring code quality improve the team's ability to improve the measurement figures. That doesn't count. More or less any measurement will be gamed if anyone think they are used for something. But has anybody measured if these measurements actually are helpfull?
Re: Worst Software Metrics
#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”.
Re: Worst Software Metrics
#6Does anybody know of a study documenting that measuring and reporting software code quality metrics actually improve the project/product team's ability to deliver? So far I've only found studies documenting that measuring code quality improve the team's ability to improve the measurement figures. That doesn't count. More or less any measurement will be gamed if anyone think they are used for something. But has anybod…
Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."
Re: Worst Software Metrics
#7Actually, 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)
And at the same time you still can't use LoC to measure productivity and reward for it because of the Goodhart's law.
Re: Worst Software Metrics
#8Does anybody know of a study documenting that measuring and reporting software code quality metrics actually improve the project/product team's ability to deliver? So far I've only found studies documenting that measuring code quality improve the team's ability to improve the measurement figures. That doesn't count. More or less any measurement will be gamed if anyone think they are used for something. But has anybod…
This is a terrific question, and a topic I've thought about quite a bit while we've built our product (context: as the OP, I've toiled on "how to prove metrics are signal-bearing" for a couple years now).
The problem we always end up at is "what measurable output can we rely upon to tell the story that a project's fortunes are improving"? To date, its been challenging to find a compelling answer. This may be why I'm unaware of any study that addresses the question.
One possible workaround would be to take experts in the field, and try to translate their qualitative interpretation into input that drives a metric. e.g., if Andrew Clark from React could list three directories that harbor disproportionate tech debt in their project, we could calibrate our Open Repo Directory Browser to identify the factors that were unique to that directory. This could then help managers pick out when and where its appropriate to make payments to reduce their tech debt.
Unfortunately, the prominent open source developers aren't answering my emails at this point. And even if they did, it's still a long road to translate qualitative expert opinion into provable long-term benefits. But I think the environment for making that leap is as ripe as ever. We just need to keep working toward figuring out the most desirable+measurable outputs.
Re: Worst Software Metrics
#9Actually, 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)
You're discussing it as a negative metric/limiting factor/base constant type of thing, but that's not the context in the article: >Thus, the "most valuable developer" as measured by LoC tends to be whoever is adding the most CSS, whitespace, and third-party libraries. It's still as terrible as ever to positively correlate developer productivity/quality/skill with LOC.
Of course, that developer almost certainly introduced the most bugs, as well. So, maybe? :)
Though, agreed you are almost certainly better pulling back up and asking more product faced questions. The most prolific author, as an example, produced more sentences read by someone. Not just more sentences.
Re: Worst Software Metrics
#10Actually, 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.