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.
> 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.
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.
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
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.