6 ms·

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

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.

mc32 8y ago
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...
- garmaine 8y ago
  Better understanding of materials, and better recognition that “once in a century” events do happen.
  - mc32 8y ago
    The once in a century thing is much less troubling than say one failure cascading into multiple catastrophic failures.
    - garmaine 8y ago
      They didn’t have the capability of the time to do cascading failure analysis of that type.
    - markrages 8y ago
      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.
      - mc32 8y ago
        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.
        garmaine 8y ago
        Earthquakes and other natural disasters follow a random distribution over time.
        Someone 8y ago
        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-the-difference-between-mtbf-and-lifetime/6ad305337bb802105d3d31475330306d.html https://www.controleng.com/single-article/learn-or-review-th...)
      - Someone 8y ago
        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.
      - ebullientocelot 8y ago
        I don't think an assumption of uniform random distribution is fair.
- pfdzm 8y ago
  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 https://en.wikipedia.org/wiki/Factor_of_safety
  - jaclaz 8y ago
    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.
- CydeWeys 8y ago
  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.
- vlehto 8y ago
  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.
lisper 8y ago
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.
ebikelaw 8y ago
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.
mikestew 8y ago
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.
stcredzero 8y ago
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.
- jandrese 8y ago
  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.
  - stcredzero 8y ago
    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.
    - Aloha 8y ago
      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.
astrodust 8y ago
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/ http://books.wwnorton.com/books/Why-Buildings-Fall-Down/ Lessons for software engineering right there.
- mathgenius 8y ago
  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.
  - Nasrudith 8y ago
    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.
    - Filligree 8y ago
      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.
thisrod 8y ago
> 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.

mc32 8y ago

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

garmaine 8y ago
Better understanding of materials, and better recognition that “once in a century” events do happen.
- mc32 8y ago
  The once in a century thing is much less troubling than say one failure cascading into multiple catastrophic failures.
  - garmaine 8y ago
    They didn’t have the capability of the time to do cascading failure analysis of that type.
  - markrages 8y ago
    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.
    - mc32 8y ago
      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.
      - garmaine 8y ago
        Earthquakes and other natural disasters follow a random distribution over time.
      - Someone 8y ago
        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-the-difference-between-mtbf-and-lifetime/6ad305337bb802105d3d31475330306d.html https://www.controleng.com/single-article/learn-or-review-th...)
    - Someone 8y ago
      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.
    - ebullientocelot 8y ago
      I don't think an assumption of uniform random distribution is fair.
pfdzm 8y ago
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 https://en.wikipedia.org/wiki/Factor_of_safety
- jaclaz 8y ago
  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.
CydeWeys 8y ago
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.
vlehto 8y ago
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.

lisper 8y ago

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.

ebikelaw 8y ago

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.

mikestew 8y ago

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.

stcredzero 8y ago

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.

jandrese 8y ago
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.
- stcredzero 8y ago
  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.
  - Aloha 8y ago
    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.

astrodust 8y ago

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/ http://books.wwnorton.com/books/Why-Buildings-Fall-Down/ Lessons for software engineering right there.

mathgenius 8y ago
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.
- Nasrudith 8y ago
  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.
  - Filligree 8y ago
    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.

thisrod 8y ago

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