[edmundsauto]

I am not a structural engineer, but have close friends who are pretty senior. In a long conversation one night, we spoke about this. He said there is a pull towards using less material / close to the minimums, driven by the builder. But the engineering team has final say (modulo their customer finding another shop).

Most relevant, he said in his experience, everything is still overbuilt. They engineer it to meet spec, then add in safety factor of 2-8x. (Said safety factors are also part of the specification, interestingly! What if software estimates had a specific set of fudge factor guidelines like this?)

[ethbro]

The difference between physical engineering and computing is that their world is unknown, while ours is known.

Both of these subject to individual exceptions, but broadly true.

You can't request a steel or wood beam and then say "Here are its exact properties".

You can instatiate a class of MyFooType and say "Here are its exact properties".

In that sense, physical engineering is essentially a Bayesian approach, where reality is always unknown. But with high probability greater than some number of deviations from the mean.

Source: architecture / BC major before CS

[edmundsauto]

Respectfully, I strongly disagree. Software components, in isolation, may be understandable. Software systems are significantly more complex and often have completely unexpected properties.

Not to dismiss the challenges of physical engineering, but as you say -- it's essentially Bayesian, with very strong priors available. Physical reality, on the human scale, can be comprehended with relatively straightforward equations, mod some fudge factor. We can account for the unknowns in the physical world with that; whereas software's complexity isn't limited to linear changes -- complexity can quickly grow exponentially.

[gamblor956]

Shared this with the engineers and programmers at my company. They all had a good laugh.

Software is deterministic. Reality is not. Engineering is significantly harder than programming, and programmers have only themselves to blame for not properly handling failure modalities.

[ethbro]

No harm intended to the GP's feelings, but glad someone got a chuckle.

I feel really bad for the poor (insert variety of) biologists on here.

[edmundsauto]

I think we're using different meanings for software. I'm using it to include all things around building software -- requirements gathering, writing, shipping, maintaining, ops, deployment, etc.

Software is not predictable. That's why nobody can accurately predict how long a project will take.

[gamblor956]

Software is predictable compared to reality because every part of it is deterministic, or can be programmed to be deterministic.

The fact that most programmers are incapable of properly coding their software to be deterministic says more about the quality of the programmer than the difficulty of the field.

[edmundsauto]

Reality doesn't have to be deterministic to be predictable. Software components can be (theoretically) deterministic and still have unpredictable behaviors in complex systems.

The fact that these welders didn't clean the acetylene edges doesn't mean that this outcome was unpredictable. Wouldn't it say as much about the welders as the difficult of the field?

[maxerickson]

I think the other posters usage of overbuilt implies exceeding a reasonable safety factor.

[edmundsauto]

The begs the question: what is a reasonable safety factor? My structural eng friends say they disagree all the time with the builders on that front. They even disagree with each other.