Listening to Dylan Beattie is always a treat. He knows how to pick interesting subjects and also how to present them in an engaging and entertaining fashion.
I love listening to Dylan, and sometimes I get so engrossed in whatever historical subject he's delving into that I forget he's giving a software talk.
Feynman wasn't the first person to know about the O-ring failures on the Challenger. Three Morton-Thiokol engineers knew the night before the disaster that they would fail. They tried to stop the launch but were stopped by NASA managers because " Reagan was had demanded a launch". The three engineers were fired for "whistleblowing" because the would not shut up. The whole story is told in IEEE Spectrum magazine in a 1989 article about the problems the three engineers experienced. The booster O-ring specifications required that ambient temperature must be 48F for 24 hours before the launch and NASA had this information. Political pressure led to a launch after days of freezing temperatures. That's like knowingly buying tires rated for 100mph and then driving at 150mph. The design was rated for 48F or higher and NASA bureaucrats chose to launch at 32F. The result was a certain failure.
"Failure is not an option" (it's included as part of the base package) That aside, there is a book by Nathaniel S. Borenstein called "Programming as if people mattered" that you may find worth a read. I don't know if it's still in print, though. I work in the aerospace industry as a software engineer. We endeavor to design systems as though failure is an inevitability, and try to make sure that all failure conditions that can be anticipated are handled, and that any unanticipated failures cause conditions that will do the least damage. For flight instrumentation, it is better to provide no information than wrong information, often the mitigation is to shut down the subsystem and alert the crew. When I started working in this domain I was given the task of designing and implementing software within the platform to deal with loss-of-cooling failures (fan failure, ventilation blockage, the plane sitting on the tarmac in the sun for 2 hours, things like that). I had come from a different part of the computer industry where graceful degradation was the goal when handling failures; I designed a health monitor that would lower the CPU and memory clock speed and/or turn off the clocks to non-critical components to reduce power dissipation but keep this safety critical subsystem operating. My design was unacceptable because there was no guarantee that the subsystem would always produce the same data to the displays that the pilot relies on when going full-rate (no failures) and with an overheat condition. The correct solution, I learned, was to stop reporting anything and put the entire subsystem into as close as a reset state as possible until the conditions were within tolerances. There were 3 copies of this same subsystem on the airframe, each in a different physical location but receiving the same stimulus (data from sensors and discrete signals), and the display subsystem used voting to select the source of the data it displayed to the crew. Stale or improperly smoothed data would not match between the different copies, and this could result in the wrong data getting displayed. When one of the modules went off-line, the display would source select between the two other modules. If they disagreed, the display would highlight the measurement to alert the crew that alternative readings should be consulted. Failure tolerance is a design constraint that is tuned up or down depending on the criticality of the system, whether it is mission or safety critical system, and what the consequences of any failure might be.
That's really interesting... thanks for the comment; I'll see if I can track down a copy of the book! Also, by a random coincidence, Nathaniel Borenstein just popped up in the research I'm doing for my next talk - he's mentioned in the Wikipedia article about MIME email formats, quoted talking about the problems of defining MIME version 1.0 without sufficiently specifying how that would then lead to 1.1 or 2.0. Interesting stuff. :)
28:00 In Australia, we had a similarly catastrophic implementation of a similar system for welfare payments that wrongly identified many people for welfare fraud and demanded repayments that people didn't owe and couldn't repayment. Quite a few people lost their lives.
same over here in the netherlands. the cabinet fell and didn't recover. never blindly trust computers on high stake actions unless the system is designed for it hint: almost all systems are not designed for high stake actions
@@zuighemdanmaar752 I wish we could say our cabinet fell and couldn't recover after the utterly inhumane Robodebt debacle, but Australians really love voting against their own interests, and conservatives really love screwing working people over.
I would not have expected RICHARD FRICKEN FEYNMAN to identify that the rubber seals had failed, and the "root cause" was increasingly lax risk assessment over time. I can't imagine what they were thinking letting him, the last person to be a yes-man, conduct an assessment.
technically he didn't - he was given the info by whistleblower (and Astronaut) Sally Ride to look in that direction by providing NASA documentation on the O-rings and their resilience against temperature. She is the true hero of the Rogers Commission which looked into the Challenger Disaster.
@@davidpriestley1650 R Feyname just put a bent over bit of seal in a glass of ice water with a pipe clamp holding it in place. But at the hearing were no one would sell him to be quiet.
I expect that he was all of these: not involved, independent (his job did not depend on NASA) convinced by the evidence placed in front of him vocal highly reputed (unassailable) publicly known So they couldn't shut him up and they knew the problem wasn't going to go away now with him pursuing the matter.
This was one of the best presentations I've seen in a while. Thought provoking, engaging, and entertaining. It's already sparked several great discussions and I just finished watching it.
@@grumblycurmudgeon if you think there's a field where failure has never occurred, either your definition of failure or your domain of analysis is too narrow.
im confused wym by this lol like, what i can think of is `(2 + 1) == 4` should always fail, meaning a requirement, and if it doesnt fail, somethings very wrong is that wht u meant
@@ari_archer if you're talking about the OP, the meaning i interpreted was "if you try hard enough in any domain, you will necessarily fail many times on the way to success"
in the early 1990s, I worked with IBM Federal Systems who were the people who wrote the primary (4 copies) flight control system for the shuttle. They were very proud that the 5th computer never did have to take over because they'd built so much resilience into their one (same principle as the whole Saturn V availability story).
Failure is always an option, has been my saying for years. I’ve experienced it, along with huge success. What’s required is to learn, iterate, change, adapt. When in many cases, your psyche is screaming “I’m done, I’m not doing this shit again”.
Post Office. Even when the people in charge know the computer system was wrong, they still sent the people prison then admit it failed. That is true EVEL (This comment was made before I heard the rest of the segment. I still believe it is true)
Thanks Dylan, another engaging talk. SMS verification code timeout as discussed at 32m 0s in video. I had this exact think last week. Phone SIM dead (network problem), in one of the provider's high street shop's on their WiFi, using WiFi calling to call the support number. The SMS message was delayed by a FEW SECONDS when on WiFi and the authentication timed out. Timeout was about ten or fifteen seconds. Luckily I didn't hang up immediately on one occasion and it fell through to a manual process. I very nearly didn't discover this because a few times I hung up on getting the "Ha ha Too Late" audio message.
Hahaha the Brandenburg Airport is a really big shame for us germans, we always laugh about it. Its terrible that the whole world knows about it now :( What a shame ^^
Great talk. Thank you. At the print shop in the Principality of Liechtenstein where I did my apprenticeship, they had two Linotype machines standing around. I was told that one of them should still work, but I've never seen them in operation. And I don't know if they still have them.
It's a language where the first thing that happens is all the variables are loaded into the stack. It has the huge performance benefit that you know the stack size right at the beginning so the OS doesn't have to use any guesswork to figure it out or anything.
Wonder how hard it would be to create a language called "10x"... It could be just like C but all numerical data types implicitly become the natural log of the number declared, to varying precision depending on the type
I was just commenting on how much I hate the phrase "full-stack developer." Dylan mentioned in the talk his creation of Rockstar was the impetus behind LinkedIn no longer looking for "Rockstar developers". I'm just saying should the flight ever take him again, please: let's neutralize another overused and frankly destructive descriptor, and get double mileage outta the gag. ...but really just an instruction queue could be considered a stack... maybe something that fully evaluates a current set of instructions before allowing for the injection of more (the "full-stack must be used up before accepting additional input")? I could see there being an actual value in low-level microcontroller-oversight, or manufacturing...
19:30 I found the chart confusing for a minute because it suggested that the number of random defects is highest at the start of the lifecycle, rather than just being additive.
You should listen to Allan McDonald talk about the Challenger failure. They knew it was a problem and he refused to sign off on the launch which forced his superior in the company to have to sign off. The engineers didnt have a yolo attitude. NASA changed the question from "is it a good idea" to "prove it will fail."
"It's about a bunch of astronauts who go into space. They're on their way to the moon. The ship blows up. It looks like they're all going to die and then they don't die and they get them back and everyone goes, 'yay, America is amazing'." looks like that's about 46 words [1], which is close enough to 20. well, same order of magnitude, or thereabouts. certainly close enough for a figure of speech. [1] counting each contraction as a single word, and omitting gap words like "um". if we instead count expand each of the 3 instances of contraction, and include the (single) gap word ("uh", after "space"), then it comes to 50 exactly, which is still only 2.5x twenty, so still close enough in my book. but yes, i did check. i guess i'm "that guy".
Failure is when you quit. Not meeting success isn't failure, and in the rapid prototyping mindset it doesn't make sense to quit and be emotional after not meeting success on the first try. Movies where "scientists have a big mission and something goes wrong" so they scrap the whole project - these are as far from reality as movies where the unpowered main character survives a 30 story fall onto pavement. You might die of old age on the road to success, but so long as you don't give up you won't fail.
People fear air travel because the probability of death in event of a crash is very high, whereas most car accidents result only in damage to the vehicle and minor injuries.
*_FMECA_* ... different failures, different modes. Some things probably won't fail, some things likely will. Some things are easy to diagnose and fix, other things ... not so much. Criticality matters! _cheers_
Im living in a modern house in a city centre. A modern building made from concrete... I dont know why, but either its 5G, E or straight up nothing at all.
18:10 "80.000 flights landed safely" is not news the same way "4.000 people die in car crashes every day" because we suck at numbers! If 4.000 people got into one massive car pile up the horror would be plain to everyone to see, but because each individual instance is maybe 1 or 2 folks it's suddenly not worth thinking about.
Bro I liked ur talk until you made up the roots of chaos theory. Chaos theory was invented by Poincare when he tried to win a competition set by another mathematician to proof the stability of the celestial mechanics.
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
Listening to Dylan Beattie is always a treat. He knows how to pick interesting subjects and also how to present them in an engaging and entertaining fashion.
That's nearly word for word what I was about to say :)
I only just found out about him somehow and have been going on a binge, every talk is interesting
I love listening to Dylan, and sometimes I get so engrossed in whatever historical subject he's delving into that I forget he's giving a software talk.
failure is not an Option, it's a Result::Err
rust lore
or {panic}
STDOUT
Failure Oriented Programming 😅
@@clooskey Did someone say FOP? I see you worked in Angular2 for a time as well!
Feynman wasn't the first person to know about the O-ring failures on the Challenger. Three Morton-Thiokol engineers knew the night before the disaster that they would fail. They tried to stop the launch but were stopped by NASA managers because " Reagan was had demanded a launch".
The three engineers were fired for "whistleblowing" because the would not shut up. The whole story is told in IEEE Spectrum magazine in a 1989 article about the problems the three engineers experienced.
The booster O-ring specifications required that ambient temperature must be 48F for 24 hours before the launch and NASA had this information. Political pressure led to a launch after days of freezing temperatures. That's like knowingly buying tires rated for 100mph and then driving at 150mph. The design was rated for 48F or higher and NASA bureaucrats chose to launch at 32F. The result was a certain failure.
Just gotta mention that Ed. Lorenz's Royal McBee LGP-30 (34:38) was programmed by.... Margaret Hamilton (05:15) - before she went to work for NASA.
Wow, I had no idea... today I learned. Thanks!
More info about it here: www.wired.com/story/these-hidden-women-helped-invent-chaos-theory/
Dylan Beattie tech talks never fail to impress! Yet another fine one!
"Failure is not an option"
(it's included as part of the base package)
That aside, there is a book by Nathaniel S. Borenstein called "Programming as if people mattered" that you may find worth a read. I don't know if it's still in print, though.
I work in the aerospace industry as a software engineer. We endeavor to design systems as though failure is an inevitability, and try to make sure that all failure conditions that can be anticipated are handled, and that any unanticipated failures cause conditions that will do the least damage. For flight instrumentation, it is better to provide no information than wrong information, often the mitigation is to shut down the subsystem and alert the crew.
When I started working in this domain I was given the task of designing and implementing software within the platform to deal with loss-of-cooling failures (fan failure, ventilation blockage, the plane sitting on the tarmac in the sun for 2 hours, things like that). I had come from a different part of the computer industry where graceful degradation was the goal when handling failures; I designed a health monitor that would lower the CPU and memory clock speed and/or turn off the clocks to non-critical components to reduce power dissipation but keep this safety critical subsystem operating. My design was unacceptable because there was no guarantee that the subsystem would always produce the same data to the displays that the pilot relies on when going full-rate (no failures) and with an overheat condition. The correct solution, I learned, was to stop reporting anything and put the entire subsystem into as close as a reset state as possible until the conditions were within tolerances. There were 3 copies of this same subsystem on the airframe, each in a different physical location but receiving the same stimulus (data from sensors and discrete signals), and the display subsystem used voting to select the source of the data it displayed to the crew. Stale or improperly smoothed data would not match between the different copies, and this could result in the wrong data getting displayed. When one of the modules went off-line, the display would source select between the two other modules. If they disagreed, the display would highlight the measurement to alert the crew that alternative readings should be consulted.
Failure tolerance is a design constraint that is tuned up or down depending on the criticality of the system, whether it is mission or safety critical system, and what the consequences of any failure might be.
That's really interesting... thanks for the comment; I'll see if I can track down a copy of the book! Also, by a random coincidence, Nathaniel Borenstein just popped up in the research I'm doing for my next talk - he's mentioned in the Wikipedia article about MIME email formats, quoted talking about the problems of defining MIME version 1.0 without sufficiently specifying how that would then lead to 1.1 or 2.0. Interesting stuff. :)
28:00 In Australia, we had a similarly catastrophic implementation of a similar system for welfare payments that wrongly identified many people for welfare fraud and demanded repayments that people didn't owe and couldn't repayment. Quite a few people lost their lives.
same over here in the netherlands. the cabinet fell and didn't recover. never blindly trust computers on high stake actions unless the system is designed for it
hint: almost all systems are not designed for high stake actions
@@zuighemdanmaar752 I wish we could say our cabinet fell and couldn't recover after the utterly inhumane Robodebt debacle, but Australians really love voting against their own interests, and conservatives really love screwing working people over.
I would not have expected RICHARD FRICKEN FEYNMAN to identify that the rubber seals had failed, and the "root cause" was increasingly lax risk assessment over time. I can't imagine what they were thinking letting him, the last person to be a yes-man, conduct an assessment.
Probably that they actually wanted the problem addressed.
technically he didn't - he was given the info by whistleblower (and Astronaut) Sally Ride to look in that direction by providing NASA documentation on the O-rings and their resilience against temperature.
She is the true hero of the Rogers Commission which looked into the Challenger Disaster.
@@davidpriestley1650 R Feyname just put a bent over bit of seal in a glass of ice water with a pipe clamp holding it in place. But at the hearing were no one would sell him to be quiet.
I expect that he was all of these:
not involved,
independent (his job did not depend on NASA)
convinced by the evidence placed in front of him
vocal
highly reputed (unassailable)
publicly known
So they couldn't shut him up and they knew the problem wasn't going to go away now with him pursuing the matter.
This was one of the best presentations I've seen in a while. Thought provoking, engaging, and entertaining. It's already sparked several great discussions and I just finished watching it.
His talks are all great, the Code as Art one and the whole thing about quines is very cool
@@tlrkendl Seen it, loved it! Next time someone asks me to do FizzBuzz I'll try to bust out Dylan's version :P
If you try hard enough, failure is not only an option - its a requirement.
On behalf of all the smoking craters that never were, upstaged instead by spacecraft successfully landing, I must respectfully counter, "nuh-uh!"
@@grumblycurmudgeon if you think there's a field where failure has never occurred, either your definition of failure or your domain of analysis is too narrow.
im confused wym by this lol
like, what i can think of is `(2 + 1) == 4` should always fail, meaning a requirement, and if it doesnt fail, somethings very wrong
is that wht u meant
@@ari_archer if you're talking about the OP, the meaning i interpreted was "if you try hard enough in any domain, you will necessarily fail many times on the way to success"
In modern world, every company "thinks" that they know better, than their user. Every product is made, to force you, to do it "right" way.
Yeah. I'd say it's the fault of the person who coined the phrase "opinionated software".
in the early 1990s, I worked with IBM Federal Systems who were the people who wrote the primary (4 copies) flight control system for the shuttle. They were very proud that the 5th computer never did have to take over because they'd built so much resilience into their one (same principle as the whole Saturn V availability story).
Copenhagen... So close to me, yet I have not been able to go yet :( - Want to see Beattie live so bad
"Failure is not an option - it is mandatory. The option is whether or not to let failure be the last thing you do" (70MMEM) 😉
Super awesome talk. It really did teach me to think of failure in layers. It applies more and more the bigger you scale.
Failure is always an option, has been my saying for years. I’ve experienced it, along with huge success. What’s required is to learn, iterate, change, adapt. When in many cases, your psyche is screaming “I’m done, I’m not doing this shit again”.
As a German the Berlin airport example really hurt
Ja :D Ist echt peinlich dass es auch international ein Lacher ist.
@@amanda.collaud Zum Glück wohne ich nicht in Berlin 😅...
@@thepaulcraft957 Ich schon *heul*
Post Office. Even when the people in charge know the computer system was wrong, they still sent the people prison then admit it failed. That is true EVEL (This comment was made before I heard the rest of the segment. I still believe it is true)
Loved the section about Kenya!
Me too. Shows that you have to be clever to upcome certain obstacles
Amazing Presentation
It's so great listening to Dylan. Thanks so much!
Thanks Dylan, another engaging talk.
SMS verification code timeout as discussed at 32m 0s in video. I had this exact think last week. Phone SIM dead (network problem), in one of the provider's high street shop's on their WiFi, using WiFi calling to call the support number. The SMS message was delayed by a FEW SECONDS when on WiFi and the authentication timed out. Timeout was about ten or fifteen seconds. Luckily I didn't hang up immediately on one occasion and it fell through to a manual process. I very nearly didn't discover this because a few times I hung up on getting the "Ha ha Too Late" audio message.
WOW I use MPESA for everything and I didn't know how it started, I've always been curious about it. Thanks.
This guy was awesome to listen to.
Hahaha the Brandenburg Airport is a really big shame for us germans, we always laugh about it. Its terrible that the whole world knows about it now :( What a shame ^^
Great talk. Thank you. At the print shop in the Principality of Liechtenstein where I did my apprenticeship, they had two Linotype machines standing around. I was told that one of them should still work, but I've never seen them in operation. And I don't know if they still have them.
"try it and see what happens" is always a good idea when combining human lives and aviation
Jesus... next time you invent a language, PLEASE call it "Full-Stack"?
It's a language where the first thing that happens is all the variables are loaded into the stack. It has the huge performance benefit that you know the stack size right at the beginning so the OS doesn't have to use any guesswork to figure it out or anything.
Wonder how hard it would be to create a language called "10x"...
It could be just like C but all numerical data types implicitly become the natural log of the number declared, to varying precision depending on the type
I was just commenting on how much I hate the phrase "full-stack developer." Dylan mentioned in the talk his creation of Rockstar was the impetus behind LinkedIn no longer looking for "Rockstar developers". I'm just saying should the flight ever take him again, please: let's neutralize another overused and frankly destructive descriptor, and get double mileage outta the gag.
...but really just an instruction queue could be considered a stack... maybe something that fully evaluates a current set of instructions before allowing for the injection of more (the "full-stack must be used up before accepting additional input")? I could see there being an actual value in low-level microcontroller-oversight, or manufacturing...
@@grumblycurmudgeon we're aware and also riffing
@@traveller23e Isn't that sort of Forth?
Loved this talk
"..land a man on the moon and back before the end of the decade." 😂😂😂 What a user story indeed
19:30 I found the chart confusing for a minute because it suggested that the number of random defects is highest at the start of the lifecycle, rather than just being additive.
Great talk. I shall search for this NDC soon 😃
I'm part of a town where most people here, can't use cell phone verification. More and more things just won't work for this town.
You should listen to Allan McDonald talk about the Challenger failure. They knew it was a problem and he refused to sign off on the launch which forced his superior in the company to have to sign off.
The engineers didnt have a yolo attitude. NASA changed the question from "is it a good idea" to "prove it will fail."
I do actually wear a seatbelt for driving. It keeps my ass in place better during direction changes.
"It's about a bunch of astronauts who go into space. They're on their way to the moon. The ship blows up. It looks like they're all going to die and then they don't die and they get them back and everyone goes, 'yay, America is amazing'."
looks like that's about 46 words [1], which is close enough to 20.
well, same order of magnitude, or thereabouts.
certainly close enough for a figure of speech.
[1] counting each contraction as a single word, and omitting gap words like "um".
if we instead count expand each of the 3 instances of contraction,
and include the (single) gap word ("uh", after "space"), then it comes to 50 exactly,
which is still only 2.5x twenty, so still close enough in my book.
but yes, i did check. i guess i'm "that guy".
Failure is when you quit. Not meeting success isn't failure, and in the rapid prototyping mindset it doesn't make sense to quit and be emotional after not meeting success on the first try. Movies where "scientists have a big mission and something goes wrong" so they scrap the whole project - these are as far from reality as movies where the unpowered main character survives a 30 story fall onto pavement. You might die of old age on the road to success, but so long as you don't give up you won't fail.
46:38 Very important sentence
A very honorable mention: Tegel Airport kept on operational 14 years before BER could come in place.
I still fight with the issues at 31:55 ... hate the text message verification systems.
Have you tried enabling WiFi calling?
@@mikelward I figured this exist (a few months ago) but haven't enabled it.
what can fail will fail.
Having "Dylan Beattie" in the title is like "Made in Germany" in the 80s
excellent!
In Berlin they started to wonder if it would be quicker to move city nearer to the airport.
People fear air travel because the probability of death in event of a crash is very high, whereas most car accidents result only in damage to the vehicle and minor injuries.
The chance of dying in a car is still way higher than being killed in a plane.
*_FMECA_* ... different failures, different modes. Some things probably won't fail, some things likely will. Some things are easy to diagnose and fix, other things ... not so much. Criticality matters!
_cheers_
For some reason the applause at the end sound like a clap of thunder
They forgot the anti fire protection at the airport in Berlin! Germany is crashing!
Im living in a modern house in a city centre. A modern building made from concrete... I dont know why, but either its 5G, E or straight up nothing at all.
32:00 WiFi calling supports SMS messages, too.
Yes. But they are slower to arrive on my provider. 2FA recently failed for me because of this. I just commented with all the details.
visual studio beater? don't recognize that one :)
Functional programmers get confused, when someone says failure is always an option. Of course it is...
Justification of the try/catch block
This is the basis of radiation hardened chips - voting circuits allow for alpha radiation flips.
Failure is not an option, it's an undesired outcome of an activity.
As interesting as this is, I like how he sort of just slides it in there that he is Kenyan.
18:10 "80.000 flights landed safely" is not news the same way "4.000 people die in car crashes every day" because we suck at numbers! If 4.000 people got into one massive car pile up the horror would be plain to everyone to see, but because each individual instance is maybe 1 or 2 folks it's suddenly not worth thinking about.
lawl, moon-covid
5:51 Sounds somehwat off considering they send 3 people to the moon.
4:03 I see, it wasn't an option. It was a feature !
No sense
Bro I liked ur talk until you made up the roots of chaos theory.
Chaos theory was invented by Poincare when he tried to win a competition set by another mathematician to proof the stability of the celestial mechanics.
Just had to go political? (13:50)
We live in political times. Being political is not bad, even in spaces where politics aren't that relevant.