Now, everything is about how little material you can use, how close to the minimums you can get and still maintain a theoretical factor of safety. The problem is that in doing so, small mistakes have a much bigger impact.
Wikipedia has a list of bridge failures curated by inexplicable means. As I scan from the 1800s into the 1900s I see failures of iron bridges, but it isn't until 1907 (a lifetime of engineering after the Brooklyn Bridge) that I see a steel bridge fail during normal conditions, and that is during construction. (Not having a support washed out or a being struck by a steamer.)
As an aside, Washington Roebling's father was remembered as a great engineer, but he was also an incredibly abusive and cruel husband and father, leaving Washington with significant psychiatric sequelae that affected him throughout his life:
https://www.nytimes.com/2017/08/08/books/review/erica-wagner...
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?)
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
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.
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.
I feel really bad for the poor (insert variety of) biologists on here.
Software is not predictable. That's why nobody can accurately predict how long a project will take.
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.
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?
I looked it up, and it turns out that there was an elephant march, but it was delayed until long after the (for-humans) opening, but still was a big spectacle:
https://ephemeralnewyork.wordpress.com/2011/12/22/the-elepha...