TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Age of Invisible Disasters (2017)

148 pointsby rrampageover 6 years ago

31 comments

pdkl95over 6 years ago
&gt; The Therac-25 X-ray machine killed several people ... The reason? A race condition.<p>The problem with the Therac-25 was <i>NOT</i> the race condition. Complex devices will always have bugs, because humans haven&#x27;t figured out a way to do perfect, bug-free engineering. The problem with the Therac-25 was that it wasn&#x27;t designed to <i>fail safe</i>. The previous model had the same race condition bug, but it also had hardware monitors and interlocks which provided <i>defense in depth</i>.<p>The lesson of the Therac-25 <i>is not</i> writing perfect software; the lesson is recognizing that humans make mistakes so anything remotely safety-critical needs to be designed to fail safely when - not if - mistakes&#x2F;bugs happen.
评论 #17846855 未加载
评论 #17848330 未加载
评论 #17847368 未加载
评论 #17846449 未加载
评论 #17847045 未加载
misja111over 6 years ago
Many IT projects are failing because their budgets and deadlines are deliberately set too optimistically.<p>The reason for this comes from too sides: on the one hand, there is the client (either internal or external) who wants to have as many features for as little money as possible and who is many times not very good at judging if their demands are realistic. On the other hand there is the IT organization which has an incentive to comply with unrealistic targets.<p>If it is an external client, this unrealistic promise is the advantage over the competition that might get them the project. But I also see this happen regularly with internal projects where there is no competition between implementors. In that case the motivation is usually that IT management wants to have the consent of higher management to get this project started; they know that once a project has been going for a year or so, it won&#x27;t be terminated if it&#x27;s over budget or past deadlines. At the same time, if they would have tried to give realistic estimates too higher management the project might never have been approved.
评论 #17845209 未加载
评论 #17845877 未加载
评论 #17847667 未加载
zakum1over 6 years ago
The reason that software projects deliver so poorly in the corporate world is that senior executives and investors understand them so poorly that a large amount of recognition and attention goes to those who can &quot;bullshit&quot; rather than fix the problem.<p>This is particularly toxic, because often the senior executives and investors also have an interest in hiding the failure (avoiding personal accountability and avoiding write-downs on investment).<p>It is very hard to see how a culture of true reflection and learning can emerge in this environment.
评论 #17845579 未加载
评论 #17846888 未加载
评论 #17844961 未加载
underwaterover 6 years ago
The big software projects I’ve seen go bad don’t feel analogous to the bridge failure mentioned in the article. It’s more often poor project management, unclear requirements, and sub-par communication rather than a specific engineering failure.<p>Despite the lack of public post-mortems, poor project management seems to be widely recognized as a problem. But there isn’t a clear cut solution. Agile promised to save us all but seems to be implemented poorly more often than not.
评论 #17846003 未加载
magicalhippoover 6 years ago
I&#x27;m not a project manager, and I most certainly haven&#x27;t been involved in huge IT projects.<p>That said, from my POV it seems a lot of software related IT project failures is often correlated to two factors:<p>- Doing too much at once. Like replacing 6 different existing specialized systems with a single new one.<p>- Unwillingness to change the business procedures&#x2F;workflow to cater to software.<p>The lure of the single do-it-all system seems strong with certain people. But at least in my experience, one could draw from software engineering and how good software is written as separated modules with well-defined interfaces at the boundaries. If you have multiple systems with good interfaces for data exchange, it&#x27;s much easier to specialize where needed, and replace outdated or broken pieces.<p>The unwillingness to adjust the business procedures&#x2F;workflow to software needs is a huge one. Complex software is fragile. By having complex rules in the business procedures you force the software to be more complex, thus invariably making the software more fragile. If business procedures were changed to be software friendly before the software is written&#x2F;adapted, the software can be simpler and thus hopefully less fragile.
iTokioover 6 years ago
It daunts me how much software is getting unreliable, but trying to shame people to hold them accountable is naive.<p>The root of the problem is the uncontrolled complexity of modern software products.<p>Because of this complexity responsibilities are diluted, most of your code is in your dependencies nowadays.<p>If you write a casual library, are you responsible if it is flawed and used in a critical operation? Can dependencies always be carefully audited?
评论 #17844987 未加载
评论 #17844870 未加载
评论 #17845074 未加载
评论 #17844986 未加载
评论 #17845086 未加载
评论 #17844858 未加载
评论 #17844885 未加载
sidstlingover 6 years ago
A lot of the failures I experience at born from trying to solve business process problems with digitization, or digitization without ever asking if it’s the right thing&#x2F;way to do stuff. Another common problem is focusing too much on a particular set of business processes and forgetting that every IT system is part of a package of numerous IT systems that work together.<p>I live in one of the most digitized countries in the world. So we’ve naturally digitized payment for public transportation. When we did it, nobody questioned the taxation system, even though it was made in the 70ies and build around a public structure called “amter” that hadn’t actually existed for many years when then system was build. We had also gone from 271 municipalities to 98 and their borders were part of the taxation too. So the taxation rules frankly didn’t make any sense and they were needlessly complicated, yet they were digitized, as is. Naturally it was a disaster, it was even predicted by the technical team and the project leads, but nobody wanted to touch the taxation politically. It got fixed eventually, but it could have been several hundreds of million danish kroner cheaper if they had simply redone the taxation models for ticket prices before the digitization.<p>So that’s one mistake, and a common one, both in the public and private sectors. The other common disaster is building systems for specific processes without looking at the bigger picture. Like a case working system that handles the welfare process for people who are sick. Except you forget that those citizens sometimes don’t go through official communication channels, and maybe send a letter or an email to the wrong department, so you need to be able to add those documents to their digital case file. But that’s not possible and neither is sending a notice to other systems in other departments which also deal with the same citizen. I’m guessing this last issue is bigger in the public sector than in private, because we often buy our software from companies that have very little actual domain knowledge outside of what their direct customers tell them, and the case workers they use for knowledge very often lack insights in the greater architecture of running 350+ IT systems together because they work with maybe 5 of them.<p>I mean, these things aren’t deadly as the x-ray machine, but they’ve been happening for the better part of 25 years and nobody seem to have really learnt anything.
评论 #17845208 未加载
Spearchuckerover 6 years ago
There&#x27;s this book by Peter DeGrace and Leslie Hulet Stahl called Wicked Problems, Righteous Solutions. It describes all of these problems and others. It presents a number of very practical and proven solutions.<p>The book was published <i>28 years ago</i>, in 1990.<p>We use words like science and engineering in conjunction with others like computer, programming, and software. And yet there&#x27;s nothing scientific about how we don&#x27;t learn from mistakes already made decades ago. And how we keep reinventing &quot;engineering&quot; best practice and call them new names.
评论 #17846955 未加载
评论 #17846008 未加载
curtisover 6 years ago
&gt; <i>If you find yourself on a failing project, squandering tens of millions of pounds and hundreds of man-years of talent, pause for a moment. Think about the fact that almost 140 years ago, civil engineers stopped building bridges that fell down. They stopped building them because the failure of one bridge was laid bare so publicly.</i><p>&gt; <i>Think about the fact...</i><p>You can think all you want, but it&#x27;s unlikely to do anybody any good. Sometimes the fault for a failed project lies squarely with the engineers, but this is not at all the usual case. The people who are most responsible for failed software projects is <i>management</i>, and not just engineering management, but the people who engineering management reports to.<p>And the biggest problem management has is not simply lack of understanding of the nature of software development projects, but, often, a profound lack of interest in learning.<p>I don&#x27;t know what to do about that.
nickdothuttonover 6 years ago
I wondered why an obscure post of mine was suddenly popular.<p>A clarification: The Therac-25 had an unfortunate race condition, what made this deadly was the conscious decision by the designers to REMOVE the physical safety interlock. They didn&#x27;t consider modes of failure. The post says exactly this. Always consider modes of failure, you never know when some &quot;other guy&quot; is going to naively count on your work being 100% reliable. It&#x27;s a system not a goal, as I like to remind people.<p>Some of you might enjoy some of my other stuff, particularly on security: <a href="https:&#x2F;&#x2F;blog.eutopian.io&#x2F;winning-systems--security-practitioners-5.-resilience&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.eutopian.io&#x2F;winning-systems--security-practitio...</a><p>The Tay Bridge disaster was important because: 1) Before it, we had several bridge failures in the UK. 2) After it we had almost none at all. Ever. 3) The report into the disaster was responsible for this improvement. It uncovered problems with: The design, the metal used, the way it was assembled, the maintenance regime, the project management and personal relationships and personalities of the people involved.<p>I&#x27;d lay money on the cause of the recent tragic bridge collapse in Italy being one of those already cited in that 140 year old report. It&#x27;s all there.<p>Back to our own world...<p>When major IT projects fail, there is almost never a public enquiry, even when those failures are government projects, and even when they cost hundreds of millions of dollars&#x2F;pounds. These failures are repeated regularly in government, and daily in the private sector.<p>Many of us who have been around a while have a (probably pretty good) understanding for why they fail, yet the lessons are not learned and there is little sign we are getting any better at all at not-failing. I suspect a bit of exposure to downside risk, or &quot;skin in the game&quot; as Taleb would call it, might improve things. Sometimes the medicine is hard to take.
vinceguidryover 6 years ago
&gt; I count £20b in failed IT projects over the last decade alone.<p>It&#x27;s hard to grasp the sheer <i>scale</i> of government. This article does a good job of juxtaposition in the case of the magnitude of engineering failures, but I want to add on that $20 billion is chump change when it comes to waste. The military sector alone plowed through $700 billion last year to accomplish the task of robo-killing brown people. The entire federal budget was $2 trillion. Stop and think about those numbers for a bit.<p>There are 2.8 million civil servants in the US, and 2 million military personnel. $2T divided by 4.7 million means <i>every single government official</i> is responsible for roughly $425,000 of your tax dollars. This includes postmen and every boot camp trainee.<p>Obviously only a fraction of these people are making decisions. So you can add zeroes to that number when you want to consider how much power the actual decision makers have. These decision makers are human, and humans are wont to see themselves as kings of their domain, and what is a king&#x27;s job but to squander money squabbling over fiefdoms.<p>The sheer, mind-boggling scale of systems of government, all of them, from your homeowner&#x27;s association to your neighborhood council to your city government to your state government to the national government to international governmental organizations like NATO and the UN, isn&#x27;t even the most interesting aspect to consider here.<p>A more amazing thing to think about is how they manage to get anything done at all. But that&#x27;s not even the biggest thing.<p>The biggest thing is that there is nothing new about this state of affairs. Civilization was built like this, thousands of years ago.<p>It&#x27;s an admirable goal to want to get rid of waste in government. But that&#x27;s an untamable firehose. You won&#x27;t even get laughed at for a proposal to save $20b of tax money. They will look at you, decide whether you&#x27;re going to look good on TV, maybe put you up in front of a camera if you&#x27;re really really really really lucky, and everything you spent your whole life learning to finally try to do will get swept into a political capital generating exercise for a <i>local</i> politician. Thanks, try again next life.<p>Governmental cruelty knows no bounds.
mprevover 6 years ago
Kind of weird that they used a novelty fake newspaper front page to illustrate this. The Scottish Scribe is a book of mocked-up newspaper front pages attempting to show how a modern tabloid might have dealt with historic events.
drinchevover 6 years ago
There is currently a huge problem with the Bulgarian Electronic Trade Register [0]. The register stopped working two weeks ago and is still not online [1].<p>It holds all company ownership data and a lot more. Right now there is no way to register a company in my country, as well as making any changes to existing companies ( e.g. changing manager, shareholders, etc. ). It is one of the most important set of data for an EU country.<p>The original problem ( leaked by the government ) is that a 4 of the RAID5 disks broke down, but it is still a mystery why recovering the data takes more than 2 weeks.<p>0 : <a href="http:&#x2F;&#x2F;brra.bg" rel="nofollow">http:&#x2F;&#x2F;brra.bg</a><p>1 : <a href="https:&#x2F;&#x2F;bivol.bg&#x2F;en&#x2F;classified-information-and-human-error-caused-trade-registers-collapse.html" rel="nofollow">https:&#x2F;&#x2F;bivol.bg&#x2F;en&#x2F;classified-information-and-human-error-c...</a>
评论 #17845036 未加载
lifeisstillgoodover 6 years ago
There are many problems with software projects but a fundamental one often not raised is it is hard to say &quot;this bridge will be built using this quality steel and this much effort and time&quot; when there are ten other companies, all looking from the outside as convincing, saying we will donit in half the time for half the cost.<p>I am not sure i have too many answers. But having a genuine profession that is required by law to sign off on any life-critical software seems a sensible starting point
UncleEntityover 6 years ago
&gt; Think about the fact that almost 140 years ago, civil engineers stopped building bridges that fell down. They stopped building them because the failure of one bridge was laid bare so publicly.<p>Yes, but how many bridge projects failed in the last 140 years because of cost overruns&#x2F;missing deadlines which is a more direct analogy for most of the arguments in TFA.<p>And I&#x27;m guessing we&#x27;re just talking about the UK since earthquakes have taken down a bridge or two in my lifetime...
评论 #17847058 未加载
louwrentiusover 6 years ago
I once read on Hacker News that in the future, the C-level people all need to be very strong in IT as any company or organisation nowadays is so much reliant on IT.<p>It&#x27;s also the message of the Phoenix Project book, which I did like.<p>The problem I have noticed is that although management does understand their businesses, it&#x27;s easy to bullshit them when it comes to IT. And they let it happen because they are not into IT and they don&#x27;t grok it. They would never treat other projects like this the same way when they would totally understand it.<p>I especially notice that as I read what higher management layers write about projects or effort, it&#x27;s high on fluffy &#x27;visionary&#x27; words but low on actual actionable vision that would help me to make every day decisions on what to prioritise.<p>I believe that the simple reason why IT projects fail is because of very mundane basic things.<p>But those are not sexy to write about. To me it&#x27;s all about:<p>- Why are we doing this? - How would you define succes and failure for this project - Who is responsible for what &#x2F; contact person - How do we work with each other and detail this - What are the guiding principles - How do we assure quality - How do we assure timely delivery - What stuff do we need, gear, licenses, etc. - P R E P A R A T I O N - do your homework, investigate things beforehand before you make choices.<p>I can go on and on. And it may bore you. But I think there is actually no true complexity involved in all those failing projects.<p>There is not something really special to IT projects. I wonder if we do pretend there is something special to them because we ourselves want to feel important in some sense.
评论 #17845219 未加载
sgt101over 6 years ago
There is some work on this : <a href="https:&#x2F;&#x2F;spectrum.ieee.org&#x2F;static&#x2F;lessons-from-a-decade-of-it-failures" rel="nofollow">https:&#x2F;&#x2F;spectrum.ieee.org&#x2F;static&#x2F;lessons-from-a-decade-of-it...</a><p>But... there are three key problems.<p>1) The time scales are long - in my experience big project failures are on a &gt;5 year time scale (because - big) I think proper studies will need to run &gt;10 years, and that&#x27;s a big ask for any academic or team.<p>2) The costs are borne by one set of stakeholders (IT) the benefits are accrued by another (next IT). Why invest to help your successor? No one is going to thank you, also you will likely be sacked faster! There is no board level education or knowledge about this. The only source of information that could convince boards that this is the right thing to do would be Mckinsey&#x2F;Bain&#x2F;BCM and those <i>&amp;&amp;^^&quot;! will never, every say this because it&#x27;s the right thing to do and they are evil. (prove me wrong!)<p>3) What do you measure? The field is immature, it&#x27;s not clear what the right inputs to check are - or what the right way to estimate the outputs are. So we need to do a lot of work now to set up the definitive studies.<p>I have an anecdote : there is a thing called The FEAST hypothesis <a href="http:&#x2F;&#x2F;users.ece.utexas.edu&#x2F;~perry&#x2F;work&#x2F;papers&#x2F;feast1.pdf" rel="nofollow">http:&#x2F;&#x2F;users.ece.utexas.edu&#x2F;~perry&#x2F;work&#x2F;papers&#x2F;feast1.pdf</a> I was a user of one of the studied systems, and I was curious about the study. I discovered that it hypothesised that development of big systems slowed as they got more complex and the data from the system I used was one of the points that confirmed this. I examined change control documents and discovered that the development of said system </i>had* slowed before the end of the study, but then it had reaccelerated, a whole load of &quot;robots&quot; had been implemented by business units consuming the system and these had not been reported in the FEAST study (IT was largely unaware) the robots started causing problems, policy changed, they were insourced, on platform development took off.<p>We need<p>- 5 year major international project to develop the art to support this - legislation that mandates system development information is stored up front and in a shared place. - legislation that mandates regular reviews that determine certain information that is signed off by an engineer. - 20 year massive project to use above information<p>I am not optimistic.. We can&#x27;t even prove that XYZ better than agile..
vjscover 6 years ago
Poor managment doesn&#x27;t always stem from ignorance or lack of understanding of how SW works. Sometimes it emanates from pressure to deliver within very tight timelines for the sake of survival of business or standing up to the competition in the market.<p>I have seen the best managers giving into ridiculous deadlines at the time of project onset just because they know that there is no other option.
dwenzekover 6 years ago
In this post, Bertrand Meyer made a similar claim taking the airplane industry as a reference.<p>&quot;When Will We Learn? Every major software incident requires a thorough and public analysis.&quot;<p><a href="https:&#x2F;&#x2F;cacm.acm.org&#x2F;blogs&#x2F;blog-cacm&#x2F;227943-when-will-we-learn&#x2F;fulltext" rel="nofollow">https:&#x2F;&#x2F;cacm.acm.org&#x2F;blogs&#x2F;blog-cacm&#x2F;227943-when-will-we-lea...</a>
hyperman1over 6 years ago
The book he wants has been written. It&#x27;s called The mythical man-month, by Fred Brooks. It does a post-mortem about what went wrong (an what went well) on the development of an IBM OS.<p>I think it contains today mostly stuff everybody knows, so it had a lot of impact on our profession. Not on the coding part, but very deeply on the management part.
gus_massaover 6 years ago
&gt; <i>Think about the fact that almost 140 years ago, civil engineers stopped building bridges that fell down.</i><p>It was written last year, but it looks like a weird sentence this year:<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Florida_International_University_pedestrian_bridge_collapse" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Florida_International_Universi...</a><p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ponte_Morandi#Partial_collapse" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ponte_Morandi#Partial_collapse</a><p>It&#x27;s even not that unusual. In <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_bridge_failures#2000–present" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;List_of_bridge_failures#2000–p...</a> I counted like 150 bridges collapses in the since 2000.
评论 #17848691 未加载
dredmorbiusover 6 years ago
A (justifiably dead) comment mentions the, erm, case, of the FBI&#x27;s Virtual Case File,a $170m project killed in 2007.<p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20130729205010id_&#x2F;http:&#x2F;&#x2F;itc.conversationsnetwork.org&#x2F;shows&#x2F;detail1688.html" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20130729205010id_&#x2F;http:&#x2F;&#x2F;itc.con...</a><p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Virtual_Case_File" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Virtual_Case_File</a><p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20051201114736&#x2F;https:&#x2F;&#x2F;www.spectrum.ieee.org&#x2F;sep05&#x2F;1455" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20051201114736&#x2F;https:&#x2F;&#x2F;www.spect...</a>
ThinkBeatover 6 years ago
Things makes me think about the poor woman who was killed by a &quot;self driving car&quot;.<p>If the software had acted as expected she would have been alive. If self driving cars become popular, coding mistakes will kill more people.<p>(Yes, they had wilfully disengaged the built in automatic breaking feature of the car in order to allow their software to control it, and the human safety engineer riding in the car, was not paying attention to the road (also because the safety egineer blidnly trusted the software runnign the car) were factor as well)
评论 #17853086 未加载
Alohaover 6 years ago
Just as big as failing safe, is not failing silently.<p>Thats the another key from the Therac-25 - it failed mostly silently - it displayed an strange message that didnt make any sense, and there was no obvious detection of a failure.<p>Software need not be bug free - for example, there is a reason we still include hardware watchdogs on embedded devices, and its largely because the watchdog is cheaper than bug free software, and will provide the same quality of service.
gonzo41over 6 years ago
The biggest errors I&#x27;ve seen is where people buy COTS for their core business. Which is usually a mistake is IT is a main driver for your business in some special circumstance.<p>Also if you do go COTS and don&#x27;t do the business change to fit the product. Trying to make COTS work your way is always so so so bad.
评论 #17844902 未加载
评论 #17844857 未加载
macleginnover 6 years ago
A bridge falling under a train and a non-delivered project don&#x27;t really have much in common. Major engineering projects keep being delivered very late or scrapped altogether, not that software is altogether different in this regard.
contravariantover 6 years ago
Using the collapse of an Italian bridge as an example of the kind of disasters that happened in the past is somewhat unfortunate, although the author couldn&#x27;t have known.
Animatsover 6 years ago
We <i>are</i> seeing bridge collapses again. Genoa last week. Florida last month.
damian2000over 6 years ago
When I see Therac it reminds me of Theranos - another medical device with that went into production with serious issues.
评论 #17845582 未加载
definedover 6 years ago
This is not the first time bridges have been used in comparison with software development.<p>From Programming Pearls, Section 7.3 [Safety Factors], by Dr. Jon Bentley, which reproduces Vic Vyssotsky&#x27;s advice from a talk he has given on several occasions.<p>&quot;Most of you&#x27;&#x27;, says Vyssotsky, &quot;probably recall pictures of `Galloping Gertie&#x27;, the Tacoma Narrows Bridge which tore itself apart in a windstorm in 1940. Well, suspension bridges had been ripping themselves apart that way for eighty years or so before Galloping Gertie. It&#x27;s an aerodynamic lift phenomenon, and to do a proper engineering calculation of the forces, which involve drastic nonlinearities, you have to use the mathematics and concepts of Kolmogorov to model the eddy spectrum. Nobody really knew how to do this correctly in detail until the 1950&#x27;s or thereabouts. So, why hasn&#x27;t the Brooklyn Bridge torn itself apart, like Galloping Gertie?<p>&quot;It&#x27;s because John Roebling had sense enough to know what he didn&#x27;t know. His notes and letters on the design of the Brooklyn Bridge still exist, and they are a fascinating example of a good engineer recognizing the limits of his knowledge. He knew about aerodynamic lift on suspension bridges; he had watched it. And he knew he didn&#x27;t know enough to model it. So he designed the stiffness of the truss on the Brooklyn Bridge roadway to be six times what a normal calculation based on known static and dynamic loads would have called for. And, he specified a network of diagonal stays running down to the roadway, to stiffen the entire bridge structure. Go look at those sometime; they&#x27;re almost unique.<p>&quot;When Roebling was asked whether his proposed bridge wouldn&#x27;t collapse like so many others, he said, `No, because I designed it six times as strong as it needs to be, to prevent that from happening.&#x27;<p>&quot;Roebling was a good engineer, and he built a good bridge, by employing a huge safety factor to compensate for his ignorance. Do we do that? I submit to you that in calculating performance of our real-time software systems we ought to derate them by a factor of two, or four, or six, to compensate for our ignorance. In making reliability&#x2F;availability commitments, we ought to stay back from the objectives we think we can meet by a factor of ten, to compensate for our ignorance. In estimating size and cost and schedule, we should be conservative by a factor of two or four to compensate for our ignorance. We should design the way John Roebling did, and not the way his contemporaries did -- so far as I know, none of the suspension bridges built by Roebling&#x27;s contemporaries in the United States still stands, and a quarter of all the bridges of any type built in the U.S. in the 1870&#x27;s collapsed within ten years of their construction.<p>&quot;Are we engineers, like John Roebling? I wonder.&#x27;&#x27;
评论 #17848718 未加载
kweinberover 6 years ago
This entire article and discussion is based on a fake headline and a false premise.... there are far fewer disasters of these kinds than there were because we learned from them. There are far fewer system failures of most technical kinds as well.<p>“Siri didn’t immediately play the right song from my Infinite jukebox at my voice command” is not a bridge collapse. “My online banking was down for an hour” is not near the inconvenience of not having banking available every evening and night before online.<p>One saving grace is that truly incompetent software projects of any size never make it off the ground (or stay up long enough to be relied on).