4 ms·

In the olden days they used to measure performance by SLOC, Source Lines of Code. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/w

by pan69 6y ago

In the olden days they used to measure performance by SLOC, Source Lines of Code. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code

stevekemp 6y ago
Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- bch 6y ago
  Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
  - gentleman11 6y ago
    Yet, if you had to build the aircraft out of metal shavings one sliver at a time in a laborious, error prone process, you might not know how far along you are but “well, we’re halfway there by mass” at least gives some measure for the project as a whole. If you game any metric it becomes trash
    - detaro 6y ago
      That assumes you have a finished plane design and know the target weight, which I don't think is what the analogy is after.
  - redis_mlc 6y ago
    > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. Actually, aircraft are evaluated on weight, the less the better. The A380 was initially 5.5 tons overweight, and that is one of the reasons it was a doomed product. That's equivalent to 55 passengers plus luggage (per trip), so Airbus would have to compensate on pricing, or provide fuel subsidies. https://www.aviationpros.com/home/news/10395627/airbus-a380-is-55-tons-overweight-customer-reports https://www.aviationpros.com/home/news/10395627/airbus-a380-... Several other airplanes were also doomed for being overweight. Boeing spent hundreds of millions of dollars to reduce weight on the 787 (I believe they saved 600 pounds): https://www.flightglobal.com/787-weight-saving-is-costly/71036.article https://www.flightglobal.com/787-weight-saving-is-costly/710... (The 787 was heavily (and famously) outsourced, so Boeing had little control of what went into it. Using more composites often increases weight initially.) OTOH, the Lancaster bomber was considered to be a great airplane because it could carry its own weight in payload (fuel and bombs.) In fact, one of the greatest bombers of all time.
  - skinkestek 6y ago
    Fun fact: in at least certain parts of offshore construction mass is used as a very reliable indicator - not of completion but of cost. A simplified version: - higher weight means more raw materials means more materials cost and time to assemble. - higher weight means fewer cranes will be competing for the lifting operations, again driving up cost. - and tangentially: higher weight of equipment also drives higher weight of supporting structures. Which means if you can save a ton in equipment it can make a huge difference. AFAIK and IIRC experienced engineers who work with calculations will have worked through decades of projects (either as part of the teams at the time or by reviewing budgets and bools afterwards) to compile cost calculations, but roughly if you tell those guys the type of the construction and the weight they already have a fair idea of the cost.
  - eeZah7Ux 6y ago
    > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. ...which is a very misleading comparison. Measuring the build by weight is a rough but not terrible metric, and it applies to cars as well. It also implies that there's such thing as reaching 100%, which is very wrong for software: most poorly written software uses 10x or 100x SLOC than what is required.
    - ryandrake 6y ago
      Yea, I get the point of the quote, but as someone actually building an airplane (in my garage), weight is something I'm constantly aware of and looking to minimize. It's not a measure of project progress, but it's a big factor in the final performance of the end product.
gentleman11 6y ago
I read that most enterprise software developers write about 3k sloc per year on huge projects, in terms of final code add size (not lines added), but that it varies quite a bit. Has anyone ever found these sorts of metrics to be helpful in their experience? Wouldn’t be any good for individual performance but what about for projects as a whole?
- marcosdumay 6y ago
  Code size is a great indicator of the complexity of some software and how much work it will be to maintain it. It is also a reasonably good, but far from perfect indicator of how much work went on building it. That measure is also one of the arguments for highly expressive languages, because developers seem to produce approximately the same length of code whatever language they use. And leads to some very good questions about why that length changes a lot from one place to another, but doesn't change much when one changes the more development-centric options (like the language or editor/IDE). But, of course, if you start ranking people based on it, it will stop being a good predictor of anything.

by pan69 6y ago

In the olden days they used to measure performance by SLOC, Source Lines of Code. https://en.wikipedia.org/wiki/Source_lines_of_code https://en.wikipedia.org/wiki/Source_lines_of_code

stevekemp 6y ago

Which reminds me of this story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

bch 6y ago
Which reminds me of this (attributed to Bill Gates): Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
- gentleman11 6y ago
  Yet, if you had to build the aircraft out of metal shavings one sliver at a time in a laborious, error prone process, you might not know how far along you are but “well, we’re halfway there by mass” at least gives some measure for the project as a whole. If you game any metric it becomes trash
  - detaro 6y ago
    That assumes you have a finished plane design and know the target weight, which I don't think is what the analogy is after.
- redis_mlc 6y ago
  > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. Actually, aircraft are evaluated on weight, the less the better. The A380 was initially 5.5 tons overweight, and that is one of the reasons it was a doomed product. That's equivalent to 55 passengers plus luggage (per trip), so Airbus would have to compensate on pricing, or provide fuel subsidies. https://www.aviationpros.com/home/news/10395627/airbus-a380-is-55-tons-overweight-customer-reports https://www.aviationpros.com/home/news/10395627/airbus-a380-... Several other airplanes were also doomed for being overweight. Boeing spent hundreds of millions of dollars to reduce weight on the 787 (I believe they saved 600 pounds): https://www.flightglobal.com/787-weight-saving-is-costly/71036.article https://www.flightglobal.com/787-weight-saving-is-costly/710... (The 787 was heavily (and famously) outsourced, so Boeing had little control of what went into it. Using more composites often increases weight initially.) OTOH, the Lancaster bomber was considered to be a great airplane because it could carry its own weight in payload (fuel and bombs.) In fact, one of the greatest bombers of all time.
- skinkestek 6y ago
  Fun fact: in at least certain parts of offshore construction mass is used as a very reliable indicator - not of completion but of cost. A simplified version: - higher weight means more raw materials means more materials cost and time to assemble. - higher weight means fewer cranes will be competing for the lifting operations, again driving up cost. - and tangentially: higher weight of equipment also drives higher weight of supporting structures. Which means if you can save a ton in equipment it can make a huge difference. AFAIK and IIRC experienced engineers who work with calculations will have worked through decades of projects (either as part of the teams at the time or by reviewing budgets and bools afterwards) to compile cost calculations, but roughly if you tell those guys the type of the construction and the weight they already have a fair idea of the cost.
- eeZah7Ux 6y ago
  > Measuring programming progress by lines of code is like measuring aircraft building progress by weight. ...which is a very misleading comparison. Measuring the build by weight is a rough but not terrible metric, and it applies to cars as well. It also implies that there's such thing as reaching 100%, which is very wrong for software: most poorly written software uses 10x or 100x SLOC than what is required.
  - ryandrake 6y ago
    Yea, I get the point of the quote, but as someone actually building an airplane (in my garage), weight is something I'm constantly aware of and looking to minimize. It's not a measure of project progress, but it's a big factor in the final performance of the end product.

gentleman11 6y ago

I read that most enterprise software developers write about 3k sloc per year on huge projects, in terms of final code add size (not lines added), but that it varies quite a bit. Has anyone ever found these sorts of metrics to be helpful in their experience? Wouldn’t be any good for individual performance but what about for projects as a whole?

marcosdumay 6y ago
Code size is a great indicator of the complexity of some software and how much work it will be to maintain it. It is also a reasonably good, but far from perfect indicator of how much work went on building it. That measure is also one of the arguments for highly expressive languages, because developers seem to produce approximately the same length of code whatever language they use. And leads to some very good questions about why that length changes a lot from one place to another, but doesn't change much when one changes the more development-centric options (like the language or editor/IDE). But, of course, if you start ranking people based on it, it will stop being a good predictor of anything.