Hacker News new | ask | show | jobs
by fotbr 2428 days ago
My memory might be wrong, but wasn't the Brooklyn Bridge built when steel was still a relatively new thing? Its properties weren't entirely understood, or even well understood, so as a result, it was tremendously over-built.

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.

6 comments

As I heard it, "Anyone can build a bridge that doesn't fall down, it takes an engineer to build one that barely doesn't fall down."
The Brooklyn Bridge started construction in 1869. The Bessemer Process for producing steel was the hot, new disruptive technology making large steel bridges feasible. Early mills attempting to use the Bessemer process routinely failed to make quality steel, so there was a level of distrust and high safety margins were well warranted.

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.)

Yes, during construction, a combination of the recommendation of one of his most trusted collaborators, William Paine (also a civil war brother in arms of Washington Roebling), and the fact that the sponsors were contemplating running Pullman train cars across the bridge led to the unprecedented decision to go 100% steel.

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...

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?)

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

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.

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.

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.

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.

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.

I think the other posters usage of overbuilt implies exceeding a reasonable safety factor.
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.
Yes, I remember hearing that they had to convince the public it was safe by having elephants cross it first.

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...

The Eads bridge[1] is also an example of a very early (opened in 1874) use of steel. I don't know about how over engineered it is, but it is still used for automobile and light rail today.

[1] https://en.wikipedia.org/wiki/Eads_Bridge