Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

Post reply on HN
Print view View original

211–220 of 306 posts

Re: How the Boeing 737 Max disaster looks to a software Developer

#211

Post by DuskStar »

lisper wrote: post #207
DuskStar wrote: post #188

Earlier quoted context omitted.

>If your attitude, airspeed, and rate of climb are all looking normal, then if the AOA says you're stalling it's almost certainly wrong. Agreed - you can certainly sanity check the AOA data with other data sources. Unfortunately, I'm not sure that will always let you pinpoint AOA as the cause - imagine some nice dirt-loving wasps have built nests in all of your pitot tubes, or they've iced over, and now those values…

> imagine some nice dirt-loving wasps have built nests in all of your pitot tubes All of them? And I didn't notice any of them during preflight? And none of them were there on the previous flight? And I didn't notice that the airspeed was not alive on the takeoff roll? Not going to happen. > or they've iced over Again, pretty freakin' unlikely on takeoff flying out of Addis Ababa. And this is another thing a pilot ca…

> > imagine some nice dirt-loving wasps have built nests in all of your pitot tubes

> All of them? And I didn't notice any of them during preflight? And none of them were there on the previous flight? And I didn't notice that the airspeed was not alive on the takeoff roll? Not going to happen.

You underestimate the abilities of people to fuck things up. Birgenair Flight 301 - one tube blocked by mud dauber wasp, leading to crash. [0] Later that year was the crash of Aeroperú Flight 603 - the static ports were covered with tape, which was never realized by the pilots. [1] (They continued flying as if their altitude and airspeed readings were accurate)

> > or they've iced over

> Again, pretty freakin' unlikely on takeoff flying out of Addis Ababa. And this is another thing a pilot can rule out by looking out of the window. If you're not in clouds, you're not picking up ice.

> Also, there are OAT (outside air temperature) sensors.

Not applicable in this instance, sure. But "are there clouds around" isn't something I'd expect the flight computer to be able to reliably detect, and that's what would have to make the decision here.

> > your engines to have failed

> Another thing that would be pretty apparent to the pilots.

I'd agree that it SHOULD be.

> No matter how you slice it, Boeing screwed the pooch bigly.

Yep. But there's still more complexity here than people seem to want to acknowledge.

0: https://en.wikipedia.org/wiki/Birgenair_Flight_301

1: https://en.wikipedia.org/wiki/Aeroper%C3%BA_Flight_603

Re: How the Boeing 737 Max disaster looks to a software Developer

#212

Post by megaremote »

quickthrower2 wrote: post #168
adreamingsoul wrote: post #75

Earlier quoted context omitted.

Recently, I had someone join my team who was instantly popular and everyone enjoyed this person's personality. I trusted this person more then I should have and during a period when I was unable to give enough attention to their code reviews, they introduced several critical bugs and defects into the production environment. I never figured out if it was ignorance or laziness. But, either way I learned a valuable less…

They are new to the team and are not getting sufficient code reviews. I wouldn’t put the blame on them. There is a lot of gotchas in an unfamiliar codebase. Although they probably should have known this and insisted on a full review if they are at senior level.

Maybe, but code reviews don't catch everything. They never can. Relying on them can also be a mistake.

Re: How the Boeing 737 Max disaster looks to a software Developer

#213

Post by toomuchtodo »

megaremote wrote: post #212
quickthrower2 wrote: post #168

Earlier quoted context omitted.

They are new to the team and are not getting sufficient code reviews. I wouldn’t put the blame on them. There is a lot of gotchas in an unfamiliar codebase. Although they probably should have known this and insisted on a full review if they are at senior level.

Maybe, but code reviews don't catch everything. They never can. Relying on them can also be a mistake.

If you can't trust code reviews for reviewing code of someone relatively new to a codebase, what can you trust (besides tests)? Despite tests and reviews, you might still introduce bugs into production code.

Re: How the Boeing 737 Max disaster looks to a software Developer

#214

Post by InclinedPlane »

Cacti wrote: post #183
ncmncm wrote: post #156

Earlier quoted context omitted.

Ultimately it was not a technical failure: the failure was in allowing the plane to be sold with such a thoroughly bad design. Thus, a management and regulatory failure. Regulatory, because FAA signed off on it, obviously without applying any of the process that would have prevented it. Management, because the cost of this debacle will be many, many times what they saved by trying to skate by with a faulty design.

The airlines knew what they were doing when they didn’t pay for the “upgrade” and they doubly knew when they didn’t pay for it after the first crash. Airline management is just as culpable in this debacle.

This is bonkers. Nobody anywhere in the world should expect that one buys an airplane which is unsafe by design. Also, the idea that there are two versions of a plane, one that kills people and one that doesn't, and if you buy the wrong one that's completely your fault is just insane.

Re: How the Boeing 737 Max disaster looks to a software Developer

#215

Post by crimsonalucard »

throwaway2048 wrote: post #24
crimsonalucard wrote: post #14

Earlier quoted context omitted.

Define what is a bug in a spec? I defined the program to do one thing and one thing only. What does does it mean when I have a bug in my definition? There's a definition for the definition? Makes no sense.

You can argue that no code ever has bugs by that logic, after all you defined the program to do one thing, and it did it, it was merely human expectation that was in error.

That's what I'm arguing. Code can be proven correct against a formal spec.

However, because we don't do proofs in software, there are bugs.

Re: How the Boeing 737 Max disaster looks to a software Developer

#216

Post by throwaway2048 »

crimsonalucard wrote: post #215
throwaway2048 wrote: post #24

Earlier quoted context omitted.

You can argue that no code ever has bugs by that logic, after all you defined the program to do one thing, and it did it, it was merely human expectation that was in error.

That's what I'm arguing. Code can be proven correct against a formal spec. However, because we don't do proofs in software, there are bugs.

Code is itself a specification.

Re: How the Boeing 737 Max disaster looks to a software Developer

#217

Post by cjbprime »

scrape_it wrote: post #11
crimsonalucard wrote: post #7

Earlier quoted context omitted.

No, I get it, but still... it's ironic. Software for a plane, though, I would want 1% code 99% proofs.

Well, to support the top parent's comment, here's what John Carmack had to say about SAAB's fighter jet: > The fly-by-wire flight software for the Saab Gripen (a lightweight fighter) went a step further. It disallowed both subroutine calls and backward branches, except for the one at the bottom of the main loop. Control flow went forward only. Sometimes one piece of code had to leave a note for a later piece telling…

Isn't Airbus's a stick pusher, though? i.e. it puts force on the stick that is hard to overpower but can be overpowered, so the pilot is still the control authority?

That's extremely different to a system that silently severely mistrims you, then tells you to disable your ability to trim electrically before you can fix the mistrim, as if that even makes sense, all while overpowering the yoke with aerodynamic load.

For the record, Airbus's three sensors haven't prevented crashes completely. Here's one where two sensors were damaged, causing the correct sensor to be treated as erroneous and lose the quorum vote:

https://en.wikipedia.org/wiki/XL_Airways_Germany_Flight_888T

Re: How the Boeing 737 Max disaster looks to a software Developer

#218

Post by crimsonalucard »

AnimalMuppet wrote: post #111
crimsonalucard wrote: post #6

Earlier quoted context omitted.

No, we can literally prove it correct based off of a specification. https://en.wikipedia.org/wiki/Correctness_(computer_science) In science nothing can be proven but in the world of logics and math, things can be proven. Bugs can arise where programs intersect in the real world.

> Bugs can arise where programs intersect in the real world. Well, the context is flight control software for airplanes. If that code is bug-free but doesn't intersect the real world, that's rather useless. And if it intersects the real world but therefore is not bug-free, that's not a great argument for proofs of formal correctness. But all of that is kind of beside the point. The MCAS specification was the wrong th…

You can prove the code correct against the spec. However you can't prove that the spec will do what you expect it to do because the spec is where the intersection with the real world occurs. Therefore, you must test the spec. Everything that falls under the spec can be formally verified to 100% correctness.

Re: How the Boeing 737 Max disaster looks to a software Developer

#219

Post by bronson »

kadendogthing wrote: post #197
Cacti wrote: post #183

Earlier quoted context omitted.

The airlines knew what they were doing when they didn’t pay for the “upgrade” and they doubly knew when they didn’t pay for it after the first crash. Airline management is just as culpable in this debacle.

Yeah, they willingly bought these planes. Airlines should be held as equable responsible.

You’re saying that Boeing intentionally sold unsafe airplanes? And the airlines, knowing this, still bought them?

Re: How the Boeing 737 Max disaster looks to a software Developer

#220

Post by jussij »

kakwa_ wrote: post #141
ncmncm wrote: post #74

This is a very good analysis, but fatally incomplete. One really essential reason those planes crashed was that each time the MCAS triggered, it acted like it was the first time. If it added 1 degree of trim last time, it adds a second this time, a third next time, up to the five degrees that runs the trim all the way to the stops. A second reason is that, under the design still on file at the FAA, it could only add…

This analysis is completely right, but in my opinion, focuses too much on the technical aspects. Is MCAS a hack? yes. Is it fixable? yes. Will the 737 MAX continue to fly for two to three decades after all the items above have been addressed? yes. But from an engineering perspective, putting an additional system to "fix" another system feels always a bit weird. Sometimes it's not avoidable (ex: cooling), but when it…

> Will the 737 MAX continue to fly for two to three decades after all the items above have been addressed? yes.

There is no doubt the MCAS can be fixed.

But I would say there with all the bad press the 737 MAX has received, there must be some doubt as to whether the 737 MAX will fly for decades to come.

I would say the flying public will need some convincing before they consider the plane safe.

> However, it's still flying today, and it's still a workhorse for cargo companies.

One of the reasons the DC10 is used for cargo, is very early on the DC10 faced it's own own 'bad design' issues that resulted in several fatal crashes.

A fault in the DC10 cargo door meant it sometimes did not close, which then resulted in an explosive decompression.

That fault and those early crashes greatly helped the 747 win the race to be the dominant wide body passenger jet of that time.

Post reply on HN