Lines of code is a terrible metric. Commits might not be.
There are plenty of days spent as a developer hunting down a strange bug only to fix it with a single character change (e.g adding "?" to a none null checked instance of a class).
The LOC does not reflect the effort and skill needed to track that down.
The commit will tell you all u need to know I guess.
But I would say u should know the productivity of your engineers by working with them, and looking at their pull requests. Anyone trying to measure engineers externally is going to get it wrong imho
Also if developers know your using LOC as a metric then they are going to over comment, and pointlessly roll out code (e.g not use concise linq or use if statements instead of switch and ? null operators) or worse commit stuff only to revert it later.
Its like if you measure on bugs fixed, ur just gonna increase the number of bugs you get cause devs will leaver them in or create them to fix them later.
Like I said, everything is individual. Replacing manual analysis is impossible, and there are exceptions - However, I've heard the statement "LOC is irrelevant" way too many times, and it's often an excuse given by lazy developers to hide the fact that they're not working ...
Hmm perhaps, I would say you shouldn't use LOC as a metric, I would say if you are, something else in your process is missing.
Like I say commits are useful to review. But even those could be misleading from the outside.
A good example, if someone external had measured my team on LOC over the past 3 months they would say their productivity has gone down. They/we have built a small react game for a client, the first month was a flurry of new code building the engine for the game etc. But the last month has all been about refinement, small tweaks to the game logic to make it more fun, fixes to obscure bugs on certain mobile devices etc.
If someone had measured the team members on commits 5 months ago, they would have seen a series of small copy changes. Not due to lazyness but due to a very frustrating product backlog issue which I was spending a lot of time fixing in the background. You could say the commits could highlight an issue here but I'd worry the blame Would be put on the wrong people
You're right, but then the article wouldn't be as controversial, so I have to exaggerate some points. I don't disagree with you, I just feel that the statement "LOC is useless" is abused by (some) developers, such that they can hide ...
Commits can also be gamed, by for instance indenting and de-indenting the same file multiple times. Everything can be gamed, and there are no single metric that works for all situations, but LOC is one metric that should be examined. However, I see your point, and I partially agree ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lines of code is a terrible metric. Commits might not be.
There are plenty of days spent as a developer hunting down a strange bug only to fix it with a single character change (e.g adding "?" to a none null checked instance of a class).
The LOC does not reflect the effort and skill needed to track that down.
The commit will tell you all u need to know I guess.
But I would say u should know the productivity of your engineers by working with them, and looking at their pull requests. Anyone trying to measure engineers externally is going to get it wrong imho
Also if developers know your using LOC as a metric then they are going to over comment, and pointlessly roll out code (e.g not use concise linq or use if statements instead of switch and ? null operators) or worse commit stuff only to revert it later.
Its like if you measure on bugs fixed, ur just gonna increase the number of bugs you get cause devs will leaver them in or create them to fix them later.
Like I said, everything is individual. Replacing manual analysis is impossible, and there are exceptions - However, I've heard the statement "LOC is irrelevant" way too many times, and it's often an excuse given by lazy developers to hide the fact that they're not working ...
Hmm perhaps, I would say you shouldn't use LOC as a metric, I would say if you are, something else in your process is missing.
Like I say commits are useful to review. But even those could be misleading from the outside.
A good example, if someone external had measured my team on LOC over the past 3 months they would say their productivity has gone down. They/we have built a small react game for a client, the first month was a flurry of new code building the engine for the game etc. But the last month has all been about refinement, small tweaks to the game logic to make it more fun, fixes to obscure bugs on certain mobile devices etc.
If someone had measured the team members on commits 5 months ago, they would have seen a series of small copy changes. Not due to lazyness but due to a very frustrating product backlog issue which I was spending a lot of time fixing in the background. You could say the commits could highlight an issue here but I'd worry the blame Would be put on the wrong people
You're right, but then the article wouldn't be as controversial, so I have to exaggerate some points. I don't disagree with you, I just feel that the statement "LOC is useless" is abused by (some) developers, such that they can hide ...
Commits can also be gamed, by for instance indenting and de-indenting the same file multiple times. Everything can be gamed, and there are no single metric that works for all situations, but LOC is one metric that should be examined. However, I see your point, and I partially agree ...