Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

11–20 of 306 posts

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

#11
post #5

Earlier quoted context omitted.

I'm not sure you understand how difficult it is to prove software correct. I've written a decent amount of Coq code. It's quite bonkers how much of proof one needs to write to get anything done. For reference, the certified compiler CompCert's code base is something like 10% code and 90% proofs.

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 it what to do, but this worked out well for testing: all data was allocated statically, and monitoring those variables gave a clear picture of most everything the software was doing. The software did only the bare essentials, and of course, they were serious about thorough ground testing.

> No bug has ever been found in the “released for flight” versions of that code.

so not quite that tests are useless because blackbox, but more that yes, it is possible to write software that facilitates showing a code will do what it says it will do.

In another note, I do feel sorry for the engineers but at the same time Airbus also has similar MCAS system, but the only thing that saves them is an extra Angle-of-Attack sensor whereas I believe the boeing relied on just one or two. Airbus had 3 AOA sensors and if 2 agreed, that was the data fed into the MCAS.

It still boggles my mind that they would place a bigger engine when the original plane was not built for it at all, this was 100% profit orientated move to prevent Airbus from taking Boeing's majority marketshare, it's highly ironic that the opposite results.

Even more infuriating is that Boeing passed it off as the exact same plane, not much extra training is necessary, along with FAA giving their blessing, now caught up in the mess.

Canada for instance is now looking to the EU for an independent auditing, as any credibility FAA has built up over the past years has taken a significant hit.

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

#12
post #3

Earlier quoted context omitted.

Well we can prove some things behave under certain conditions in a certain way. We can't prove the absence of bugs.

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.

If the spec is complex you are probably proving the bugs in the spec are indeed correctly implemented...

Edit: that said, spending the formal spec time will probably reduce the number of bugs far below than what we find normal now. But money...

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

#13

The irony of software is that it is the only discipline in engineering where results can be proven with logic. Yet we still do testing on it as if it was a blackbox.

Proving something is correct is only part of the problem. A random bit flip (no matter amount of error correction and physical hardening) and your proven-correct software goes amok. And this is just one of the many issue you can encounter dealing with the physical world.

Yeah, you're right. Can't completely get rid of tests but the irony still exists.

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

#14

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.

Yeah and then the specification at that level of specificity IS the code. How do you prove the specification is bug free?

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.

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

#15
post #5

The irony of software is that it is the only discipline in engineering where results can be proven with logic. Yet we still do testing on it as if it was a blackbox.

I'm not sure you understand how difficult it is to prove software correct. I've written a decent amount of Coq code. It's quite bonkers how much of proof one needs to write to get anything done. For reference, the certified compiler CompCert's code base is something like 10% code and 90% proofs.

It would ensure people thought about it a lot longer and harder than without those proofs, so the code had a whole lot more critical thinking done over it. Seems worth it in some areas like airplanes.

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

#16
post #9

What a stellar example of an article on a complex topic written to be clear enough for the audience to understand. I especially like the way he brought it back repeatedly to hands out the window and bitey dogs.

I also heartily agree with him that software's general laxity with regards to reliability is contagious. I've come think that calling it all "software" is dangerous, like thinking of all things made with atoms as the same.

I think we as an industry should get together, divide the work into various domains, and establish professional and ethical standards for the domains that matter. Standards with teeth, such that developers who want to do the right thing in the face of bosses insisting otherwise have the backing of their peers. And also such that developers who don't care about the right thing fear the professional consequences.

I honestly think this is something we should do regardless. But as a practical matter, if we don't governments will do it for us soon enough. Software keeps getting more important, as do its failures.

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

#17
I'm unclear on how moving the engine up causes application of power to cause the attitude to tend to go nose up. I would expect the opposite to happen. I think something else must have changed such as the center line of the engine relative to the center line of the plane. Or did moving the engine forward at the same time cause this effect?

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

#18

Earlier quoted context omitted.

Yeah and then the specification at that level of specificity IS the code. How do you prove the specification is bug free?

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.

It means that the one thing you defined it to do was not the right thing.

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

#20

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…

Interesting quote. Seems it was actually a quote of Henry Spencer by Carmack. http://number-none.com/blow/john_carmack_on_inlined_code.htm...

Note however that there were several software-related crashes in the early days of Gripen. Might not be related to exactly this code, but to the problem of regulating the feedback loops to manage the plane's purposeful instability

Post reply on HN