Hacker News Reader

Comment by Filligree | Hacker News Reader

The article mentions this. Common engineering practice today is to avoid any single points of failure, but back when this was built, the profession was high on precision engineering based off modern finite element models and other ways to more exactly determine the capacity of a bridge.

It was deliberately built without redundancy, because they thought they could achieve perfection. In fact the models they used were correct -- it was the underlying assumptions about the long-term behaviour of the materials used that were wrong.

This isn't the first such collapse, and it likely won't be the last, but it's safe to say that engineers have learned from their failures. Modern standards generally maximize redundancy. Precision is used to reliably achieve a high margin of error, rather than to get away with the minimum possible.

View on HN

So in some respect older bridges were overengineered to compensate for the lack of good modeling. Then good modelling came along and gave engineers overconfidence, now this is being corrected with better understading of materials science?

And thanks for pointing out that reliance on precision engineering might have led to safety factor reduction due perhaps to overconfidence...

Better understanding of materials, and better recognition that “once in a century” events do happen.

The once in a century thing is much less troubling than say one failure cascading into multiple catastrophic failures.

They didn’t have the capability of the time to do cascading failure analysis of that type.

Once-in-a-century actually means 1% chance per year. If you build thousands of bridges, you need a lot better than once-in-a-century, or you will have adverse events all the time.

Isn’t that affected by age and maintenance, rather than randomness? For sure bridges have finite useful lifespans, so we know in advance they need to be rebuilt or retired.

Earthquakes and other natural disasters follow a random distribution over time.

No. You can (in theory) design a bridge so that it is strong enough to withstand a 1000 year event and has a life expectancy or a single day.

An engineer may say things like “if you build it this way, do this maintenance, it will withstand 100 year events for its service life of 50 years”

You see that (in a slightly different form) with storage media. A SSD drive with a mean time between failures of a million hours typically will have an life expectancy that is significantly shorter (https://www.controleng.com/single-article/learn-or-review-th...)

I would think that depends on what kind of once-in-a-century events you’re talking about. If it is a big earthquake, chances are that, if one strikes one bridge, several others will be hit on the same day. You could have adverse events ‘only’ about every 50 years, but lose half your bridges on such days.

I don't think an assumption of uniform random distribution is fair.

Modern calculations are usually multiplied with several 'security factors'[0], anywhere between 1,1 and 1,5 as far as I can remember now (at least in Germany through a DIN [norm], and now Europe-wide via EN). These design factors come in at many different stages of the calculations, from materials to static load distribution (not sure if these are the correct terms in English)

[0] https://en.wikipedia.org/wiki/Factor_of_safety

Well, it is not like "earlier calculations" didn't take into account such safety factors, but the debate is not about existance of safety factors or their amplitude (1.3 to 1.5 has been used as far as I can remember in concrete constructions) but rather on redundancy.

To give a different example elevators/lift (those using rope cables) have usually cables that have a factor of safety 5, but they have nonetherless additionally at least one set of independent brakes.

Back to bridges and more generally reinforced/pre-stressed concrete structures, in my experience modern methods of calculation are more precise than old ones, and allow usually - given the same loads/hypothesis - to save (i.e. there is less rebar steel and cable steel) between 5% and 10% steel and/or concrete.

In practice with old methods of calculation there was a 1.05/1.10 "implied" and "hidden" additional safety factor.

The Brooklyn Bridge is the ultimate example of over-engineering to compensate for lack of good theory/modeling. It is both a cable-stayed bridge and a suspension bridge, each system of which is independently capable of carrying the entire load of the bridge. And it's also a truss bridge, though that system alone won't hold up its entire deck.

This is not so much a matter of safety factor than redundancy.

Safety factor = "it only fails if the bridge is full of heavy trucks and they all are overloaded 2X"

Redundancy = "we have 6 stays and any single one can snap and the bridge will stay intact"

Airplane wings cant have either. Because safety factor higher than 1,2 would make the plane too heavy to fly. And redundancy from multiple wings would make the system aerodynamically so unstable that snapping a single wing would still cause a crash.

In those cases you need to have very good testing program before installing the structure. And then you need a good inspection program to protect against fatigue and corrosion. The latter was missing in this case.

The book Why Buildings Fall Down is full of significant historical collapses and pretty much every one boils down to a lack of redundancy, a single point of failure.

http://books.wwnorton.com/books/Why-Buildings-Fall-Down/

Lessons for software engineering right there.

What is the lesson?

If something even slightly goes wrong with my software I don't want it to survive at all. This is the equivalent of putting dynamite on all the load bearing points of a structure, rigged to explode if they move out of place!

Software doesn't bend, it's digital.

That is something that is very context dependent. It is fine if it is essentially 'free' and of low criticality. But if you are dealing with an application where doing so would prove very expensive or cost lives it is clear that it isn't the ideal.

I'd say it's fine in the specific range where malfunctions can be expensive, but total failures aren't.

You pointed at one end of that, where the failure is equally expensive. From the other end of it, I attempt to build my Minecraft mod such that partial failures are transient and local, rather than bringing the entire game down.

> the profession was high on precision engineering based off modern finite element models

Two years ago, I organised a party for the 50th anniversary of one of Australia's first geodesic domes, which was designed and built by some undergrads in my university climbing club. It's a "hut" in a national park, and the rangers were skeptical about the structure. A 2nd year engineering student was in charge of the design: the story goes that he walked over to the parks office, showed off some printouts, and explained that the structural calculations had been done by computer. When the parks service heard that, they were sure that the structure had to be sound.

It was deliberately built without redundancy, because they thought they could achieve perfection

For some reason this reminds me of the Twitter conversation when it was discovered that T-Mobile Austria was storing passwords in plain text: "What if you get pwned?" "What if this doesn't happen because our security is amazingly good?"

Yeah, right up to the point that it isn't "amazingly good". Or one of the stays on your bridge suffers a catastrophe.

As a general engineering principle, it's probably a bad plan if the first indication that you've gotten something wrong is a catastrophic failure.

We still have a lot of prestressed concrete structures that predate good understanding of creep in such structures. Box-beam highway bridges, for example, were universally built from prestressed concrete after WW2, but creep wasn't well characterized until the late 1960s.

It was deliberately built without redundancy, because they thought they could achieve perfection.

This is eerily close the the attitude of a lot of programmers.

Generally programmers try to avoid redundancy.

I guess you could talk in abstract terms about overbuilding a program by including a large amount of self-checking and possibly even error correction, but that's a bit of a stretch.

Generally programmers try to avoid redundancy.

There is the whole "Don't Repeat Yourself" mantra.

I guess you could talk in abstract terms about overbuilding a program by including a large amount of self-checking and possibly even error correction, but that's a bit of a stretch.

That's a "bit of a stretch!?" That's how you should build anything that needs to be fault tolerant and robust. Maybe not a "large" amount, but enough, such that one error doesn't strand the user in a highly inconvenient situation. A key example: text messages that can crash Messages and leave the iPhone in a state where the user has to reboot. This has happened several times over the years! Apple programmers here on HN will shrug their shoulders and tell you that you have to let the process crash to ensure memory isn't corrupted. So why not have one process which can crash, working off a file acting as a queue, with another process monitoring attempts to process each element, and limiting the number of tries for each item on the queue? Apparently, that's too much trouble, and it's easier to just pooh-pooh people on social media.

Is it "redundant" to overbuild that part of the system? Yes. It's also much better for the user and for the company long term.

You should at least build something with the assumption that it will break, and be able to reset and normal itself without loss.

A good watchdog can be more valuable than bug free software.

You should at least build something with the assumption that it will break, and be able to reset and normal itself without loss.

Too much to ask of this generation of young programmers for something like messages on the iPhone. That's not a central feature of a smartphone anyways, right? Just let the user reboot.

I meant it was a bit of a stretch to call error checking redundancy.

It's not like redundancy we are talking about in a bridge means having superfluous pillars but that it can fail gracefully that can be handled and fixed without catastrophe. Error checking can achieve a similar goal in software.

That's exactly what we are talking about with bridge design: Overbuilding it so you can lose an element without the bridge collapsing.

There really isn't a concept of a bridge "failing gracefully". Any failure is a disaster. You can talk about a bridge being functional even after it becomes weakened by the elements or overloading or poor maintenance or some other condition, but that is another case of overbuilding.

I guess what I'm saying is that software and bridges are not very similar.

Real redundancy in software development would be to do something like having three independent teams implement each module, and then use voting logic to compare the outputs. Obviously that's not practical in most real world cases due to labor costs, limited hardware resources, and excess power consumption.

Reply on news.ycombinator.com