6 ms·

Actually, LOC isn't that bad. Studies have shown - that complexity metrics are highly correlated with LOC. - people can produce & maintain software at

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)

Benjammer 7y ago
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.
- taeric 7y ago
  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.
Kinrany 7y ago
And at the same time you still can't use LoC to measure productivity and reward for it because of the Goodhart's law.
- wbharding 7y ago
  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 ROI is higher will generally be more successful * In sales, "conversions" is a useful metric that salespeople strive toward and are validly rewarded for improving * In software, if a metric like "story points" (as decided by group via planning poker) could be generated consistently for every issue worked on, there's no apparent reason that developers or teams would be worse off if developers used "story points completed" as a goal to strive toward I suspect the prevalence of folks citing Goodhart's law is because it is usually true. But this may just be a consequence of the frequent disparity between "metrics available" and "desired underlying phenomenon." There's no fundamental reason that they can't be the same.
  - mnowicki 7y ago
    Please stick with me here, probably going to be a super long post but I'm sharing my thoughts on the whole topic end-to-end with the goal of addressing the root problem here, I agree that such a metric exists which is the same as the desired outcome. Such a metric does, in fact, exist. The metric IS the desired outcome. The problem comes when you try to write a generic, reusable formula that describes the desired outcome and attempt to implement a system that teams can use to apply the metric to their work. It ends up being effectively impossibly complex to create the formula, and even if you could create it, it would take longer it than it would to write the software that it's supposed to measure. What we're left with is 'the best that we can do', and that's what we have been doing. We absolutely COULD make more accurate(yet still very imperfect) metrics that more closely model the actual goals of a project by simply including more factors(bugs, readability of code, difficulty of feature, size of feature/LOC, number of modules/classes that the code spans or communicates with in some way, how easy-to-read and easy-to-modify the existing code that needs to be altered is, etc times 1,000,000). But adding more factors just makes the metric exponentially more complex and difficult to implement. I'm sure people have tried using way more fine-grained metrics than what we have now - but nobody knows about them because nobody uses them anymore because they weren't worth the time and effort. So we're kind of left with what we have, which in my opinion as a software engineer is definitely not good enough. Which is pretty bad, because by 'good enough' I just mean better than doing nothing at all. The only problem here that can be solved, and therefore that is worth solving, is why these metrics are still commonly enforced despite being counterproductive. Obviously managers managers-of-managers feel a need to have some nice, concrete, objective numbers that they can look at to see how well developers and teams are doing. The people pushing these metrics are often the ones who have no other way of understanding what exactly developers are doing, either because they've never written software before or because they are too far removed from the level of the guys actually writing code to pay attention to what they're actually doing beyond just looking at a single number. It makes sense for managers who don't know what engineers are doing to seek out a different way to measure their performance and progress. The solution isn't do nothing, and it's not story points or any of that BS. But what are the alternatives? The only one I can think of is, don't put a manager in a position to manage individual developers if he/she is unable to understand what those individuals are even doing. Having an experienced senior engineer with the right skillset for management directly in charge of every team is amazingly valuable in my opinion. It's also vital that those higher up on the ladder are able to trust these manager-engineers, who are basically acting as an abstraction layer between the regular engineers and higher management. A lot of teams already have this in the form of a senior engineer or software architect, my team has one and it works out amazingly. We all feel that doing a good job will be recognized and rewarded, problems are easily identified and addressed, we get things done very quickly, everyone gets along, and there's not a lot of pressure. This is just my own single anecdotal experience and it has worked out very well but I'm aware it may not always be that way, so I'm interested in hearing others thoughts/experiences/solutions
x3n0ph3n3 7y ago
> people can produce & maintain software at about 10 LOC/h. That is shocking and horrifying if that's the norm for software development.
- lalaithion 7y ago
  Over the last year, I have averaged 8.95 LOC* per hour as a full time* developer. Lines of Java + TypeScript, my two most used languages, purposefully excluding configs, html/css, etc. Assuming 8 hours of work per day; this is less than the time I spend at work, but probably more than I spend coding, due to meetings/email/overhead. 246 workdays, which is 30 days off, some of which are public holidays and the rest are vacation. I'm a relatively junior dev.
- greenshackle2 7y ago
  I agree, that's probably too many lines, considering how crappy most software is.
- perl4ever 7y ago
  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.
kabdib 7y ago
I've seen some of the worst developers commit more LOCs than others (churn in badly written code, or "cut-and-paste hell"). I've also seen developers sandbagging the metric (as well as artificially inflating code coverage measurements) by checking in fluff code; a null check on every pointer or reference parameter can get you 5-10 lines of actual live and executable code that is practically guaranteed bug-free and politically correct, even for functions you haven't really started implementing yet. Saw this being used in a USB stack once, it had been worked on by serial contractors and was a real eye-opener (when we got it, it was 5K LOC or so; we whacked it down to about 1100 LOC by removing a bunch of badly-motivated layers; removing the junk sped it up quit a bit, too). My position is that if you're evaluating people by comparing metrics, you're probably a terrible manager.
raxxorrax 7y ago
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 just as well.
- jschwartzi 7y ago
  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 https://en.wikipedia.org/wiki/Drinking_bird
alexott 7y ago
It’s really a complicated topic - is it a new project vs. maintenance, etc. In new project my metric was around 500 LOC of C++ code (production ready) per day. In maintenance, it could be a line a day (if you’re lucky).
dkersten 7y ago
Well, when comparing languages, sure. 10 lines of python gets a lot more done than 10 lines of assembly, but as a metric of how good your code is or the developer is, it’s not so great. Usually 9 lines of python is better than 10 lines of python (assuming lines means code points or statements or whatever rather than physical lines, otherwise 10 lines could be better if it’s visually laid out clearer)

Benjammer 7y ago

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.

taeric 7y ago
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.

Kinrany 7y ago

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

wbharding 7y ago
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 ROI is higher will generally be more successful * In sales, "conversions" is a useful metric that salespeople strive toward and are validly rewarded for improving * In software, if a metric like "story points" (as decided by group via planning poker) could be generated consistently for every issue worked on, there's no apparent reason that developers or teams would be worse off if developers used "story points completed" as a goal to strive toward I suspect the prevalence of folks citing Goodhart's law is because it is usually true. But this may just be a consequence of the frequent disparity between "metrics available" and "desired underlying phenomenon." There's no fundamental reason that they can't be the same.
- mnowicki 7y ago
  Please stick with me here, probably going to be a super long post but I'm sharing my thoughts on the whole topic end-to-end with the goal of addressing the root problem here, I agree that such a metric exists which is the same as the desired outcome. Such a metric does, in fact, exist. The metric IS the desired outcome. The problem comes when you try to write a generic, reusable formula that describes the desired outcome and attempt to implement a system that teams can use to apply the metric to their work. It ends up being effectively impossibly complex to create the formula, and even if you could create it, it would take longer it than it would to write the software that it's supposed to measure. What we're left with is 'the best that we can do', and that's what we have been doing. We absolutely COULD make more accurate(yet still very imperfect) metrics that more closely model the actual goals of a project by simply including more factors(bugs, readability of code, difficulty of feature, size of feature/LOC, number of modules/classes that the code spans or communicates with in some way, how easy-to-read and easy-to-modify the existing code that needs to be altered is, etc times 1,000,000). But adding more factors just makes the metric exponentially more complex and difficult to implement. I'm sure people have tried using way more fine-grained metrics than what we have now - but nobody knows about them because nobody uses them anymore because they weren't worth the time and effort. So we're kind of left with what we have, which in my opinion as a software engineer is definitely not good enough. Which is pretty bad, because by 'good enough' I just mean better than doing nothing at all. The only problem here that can be solved, and therefore that is worth solving, is why these metrics are still commonly enforced despite being counterproductive. Obviously managers managers-of-managers feel a need to have some nice, concrete, objective numbers that they can look at to see how well developers and teams are doing. The people pushing these metrics are often the ones who have no other way of understanding what exactly developers are doing, either because they've never written software before or because they are too far removed from the level of the guys actually writing code to pay attention to what they're actually doing beyond just looking at a single number. It makes sense for managers who don't know what engineers are doing to seek out a different way to measure their performance and progress. The solution isn't do nothing, and it's not story points or any of that BS. But what are the alternatives? The only one I can think of is, don't put a manager in a position to manage individual developers if he/she is unable to understand what those individuals are even doing. Having an experienced senior engineer with the right skillset for management directly in charge of every team is amazingly valuable in my opinion. It's also vital that those higher up on the ladder are able to trust these manager-engineers, who are basically acting as an abstraction layer between the regular engineers and higher management. A lot of teams already have this in the form of a senior engineer or software architect, my team has one and it works out amazingly. We all feel that doing a good job will be recognized and rewarded, problems are easily identified and addressed, we get things done very quickly, everyone gets along, and there's not a lot of pressure. This is just my own single anecdotal experience and it has worked out very well but I'm aware it may not always be that way, so I'm interested in hearing others thoughts/experiences/solutions

x3n0ph3n3 7y ago

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

lalaithion 7y ago
Over the last year, I have averaged 8.95 LOC* per hour as a full time* developer. Lines of Java + TypeScript, my two most used languages, purposefully excluding configs, html/css, etc. Assuming 8 hours of work per day; this is less than the time I spend at work, but probably more than I spend coding, due to meetings/email/overhead. 246 workdays, which is 30 days off, some of which are public holidays and the rest are vacation. I'm a relatively junior dev.
greenshackle2 7y ago
I agree, that's probably too many lines, considering how crappy most software is.
perl4ever 7y ago
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.

kabdib 7y ago

I've seen some of the worst developers commit more LOCs than others (churn in badly written code, or "cut-and-paste hell"). I've also seen developers sandbagging the metric (as well as artificially inflating code coverage measurements) by checking in fluff code; a null check on every pointer or reference parameter can get you 5-10 lines of actual live and executable code that is practically guaranteed bug-free and politically correct, even for functions you haven't really started implementing yet. Saw this being used in a USB stack once, it had been worked on by serial contractors and was a real eye-opener (when we got it, it was 5K LOC or so; we whacked it down to about 1100 LOC by removing a bunch of badly-motivated layers; removing the junk sped it up quit a bit, too). My position is that if you're evaluating people by comparing metrics, you're probably a terrible manager.

raxxorrax 7y ago

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 just as well.

jschwartzi 7y ago
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 https://en.wikipedia.org/wiki/Drinking_bird

alexott 7y ago

It’s really a complicated topic - is it a new project vs. maintenance, etc. In new project my metric was around 500 LOC of C++ code (production ready) per day. In maintenance, it could be a line a day (if you’re lucky).

dkersten 7y ago

Well, when comparing languages, sure. 10 lines of python gets a lot more done than 10 lines of assembly, but as a metric of how good your code is or the developer is, it’s not so great. Usually 9 lines of python is better than 10 lines of python (assuming lines means code points or statements or whatever rather than physical lines, otherwise 10 lines could be better if it’s visually laid out clearer)