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.
And thanks for pointing out that reliance on precision engineering might have led to safety factor reduction due perhaps to overconfidence...
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.
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.
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...)
http://books.wwnorton.com/books/Why-Buildings-Fall-Down/
Lessons for software engineering right there.
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.
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.
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.
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.
This is eerily close the the attitude of a lot of programmers.
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.
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.
A good watchdog can be more valuable than bug free software.
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.
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.
> But engineers gradually recognized that the structure had so few crucial supports that if even one of them failed, an entire section could collapse.
> “There is no robustness, or the possibility of redistribution of the forces,” said Massimo Majowiecki, an architect and engineer in Bologna, northern Italy.
> That lack of redundancy, as it is now often called, “is not necessarily inconsistent with how bridges were designed in the 1960s,” said Donald Dusenberry, a structural engineer with Simpson Gumpertz & Heger in Boston.
The design was such that as long as all of the parts worked, it remained standing. But it was also such that a very small number of failures would push the remaining supports beyond their capacity to withstand the loads, leading to collapse.
The SF-OAK bridge likely had a much higher level of what this article calls "redundancy" or more generally of simply "over design" (design for loads some multiple of normal loading) such that collapse of the top deck did not push the lower deck beyond its load holding capacity. I'm surprised that "bridge design in the '60s" (as stated in the article) did not take these details into account.