Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

101–110 of 306 posts

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

#101
post #94

I believe the relative ease — not to mention the lack of tangible cost — of software updates has created a cultural laziness within the software engineering community. -- This --^ As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. I know folks here will deride me for being "inefficient", but in the long term I still maintain from my experience…

It definitely depends what you're doing. Designing aircraft control systems? Yep, probably strive for perfection. Building a social network site, or a photo-sharing site, or an online forum? You're probably okay sacrificing some level of reliability for iteration speed.

It’s less about the domain than the impact of the code.

Bad code can kill your company or go unnoticed, depending on where it is and what it’s doing.

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

#102

Earlier quoted context omitted.

If only managers and CEOs saw it the same way.

One the other side, unless you are an artist and not dependant on your software actually being used, you have to get product out at some point. It's easy to demonize CEO and managers. We, as devs, will always find an excuse as to why the software is not ready and QA will always find new things to test to justify not putting the software out.

It depends on the real world effects of pushing software out. If the side effects are minor and its perfectionism, then sure, push it out ugly.

If it's a safety control mechanism for a car or airplane, then perfectionism needs to be applauded over faster time-to-market. If it's another chat application and changes can be easily rolled back, then push it out warts and all.

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

#103

Earlier quoted context omitted.

[citation needed] idk man, my code is pretty damn clean

I think my code is cool, too, until I look at it again 5 years in the future.

There's your problem — you're releasing too early. :-)

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

#104
post #29
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.

Even then it doesn't matter if your software is "correct" if you don't understand/have not captured all the requirements. You could write a formally verified MCAS system in Coq or whatever that still kills people because you didn't consider the case of sensor failure (because that wasn't in the requirements). Or because you didn't consider the case of double sensor failure or a combination of extremely rare hardware…

This. MCAS was the wrong thing to build. The wrong thing, correctly built, is still wrong, no matter how perfect the formal verification.

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

#105
post #80
post #42

Earlier quoted context omitted.

I have a MSc in formal methods, and this is really misleading. Surely you cannot make some proofs easily. However, how did Airbus verify that some errors simply do not exist in their fly-by-wire software (which is ~100 KLOC implemented in a subset of C)? (I'm sure Boeing also employs these techniques internally). Using abstract interpretation. There are tons of formal methods, ranging from type systems to formal proo…

As explained in this talk by Robert Martin, proving programs correct was the big goal which Edsger W. Dijkstra tried to reach by eliminating GOTO in favor of structured programming (which is essentially having if-else statements, loops and iteration as part of a language as replacement for all practical uses of GOTO). https://www.youtube.com/watch?v=SVRiktFlWxI#t=2h9m38s Software could be proven correct, but we aband…

I think Robert Martin doesn't fully grasp the field of formal methods and program semantics, which has evolved a lot since the early 1980s. Paraphrasing Alan Perlis, beware of the Turing tar pit, where everything is possible but nothing of interest is easy.

So one trick is to work on DSLs with restricted semantics that are good enough for your domain. That makes proofs plus other formal techniques, and hence security guarantees, much much easier.

But if you insist on Turing complete languages, as I explained above, you can e.g. build abstract interpreters or data flow analyses that are able to prove really sophisticated things. I have implemented a C abstract interpreter for an industrial client that among many other things detected whether you were making potential out of bounds accesses to arrays, or potentially using uninitialized pointers. Of course it erred on the safe side. But it was really precise (few false positives). Not a walk in the park as it relies on Galois connections. See the seminal Cousot & Cousot 1977 paper [1].

[1] https://www.di.ens.fr/~cousot/COUSOTpapers/POPL77.shtml

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

#106

The 737 Max keeps getting viewed as an "Engineering Failure" but we should consider if this really was a "Management" failure. The unstated goal w/MCAS was to avoid additional pilot type certification. (If you tell pilots about MCAS, give them an off switch, or if the system switches off... then pilots need to be trained specifically on the MAX.) If management gave the MCAS project to Senior Boeing Engineers they wou…

The article states that MCAS was implemented "on the hush-hush," which makes me wonder if it could even be subject to the same level of quality control as other features of the software.

It might have had to bypass some of the more stringent parts of Boeing's development process to avoid appearing in documentation that the customer or the FAA might see.

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

#107
I think a fundamental concept that is relatively ignored in press (mainstream or non-fringe at least) is in business priorities.

As the essay points out, Boeing made decisions based on market (financial) factors all along the way. Of course they did - almost all companies do. Because it's so common, we forget it's not a RULE that cost, shareholder value, profit, etc. must be the final judgement.

Certainly any company that might prioritize safety (as in the case of a people-carrier) or some other non financial focus may not be as attractive to investors, in some cases - particularly where human life is concerned - maybe that's ok.

I know this is a bit sensational of me to suggest, but Walmart could make an airplane. They have the funds to do so if they wanted (they would just buy a company; that's the quick way to get rolling). And if the Walmart airline charged half of what other airlines charged, you can be sure a whole lot of people would fly it. And sure, after enough flights, the fatalities per flight would become uncomfortable to most flyers.

The point is, it's a very long game. If people are not willing to consider the long game, they are basically gambling. I fly a lot. I almost always choose my flights based on cost/convenience. I didn't previously avoid 737 MAXs. (I would now, but they're all grounded anyway.) That said, if I know an airline cuts every corner to lower the price and increase the profits, I will certainly choose the next more expensive airline that doesn't behave so poorly. In this case it's the manufacturer, and the consumer has much less choice where that is involved.

But let's get back to the point. If Boeing were to fall behind Airbus in the 737/A320 race, would that really be such a terrible thing? Would the cost be human life, or might it be some stock price level? As an investor, do you really care about your shareholder value more than human life?

I like to fly. It can actually be fun. And I really like to visit lots of places in the world, eat lots of awesome food, and experience different cultures. I don't want to die because of some shareholder value goal (fuck you). I will die, and maybe it's tomorrow, but it shouldn't be for a stupid reason unless I choose it (here, hold my beer.)

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

#108

So, the linked article is an updated version of an earlier article in the EE times. In the comments section, a reader (ie) Frankly, I am astonished that a single point of failure (AOA) could make it through a FMEA (Failure Mode Effect Analysis). For those who are unfamiliar, a FMEA is (basically) looking at each part of a system and saying "What happens if it breaks?". Having worked in commercial vehicle software dev…

I don't work in this field. Do you have to publish the findings from this analysis? Is it possible that no such analysis was done because the MCAS system had to be kept quiet?

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

#109
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…

tl;dr the first thing you learn doing control systems is NEVER use += 1; when it relates to an electro-mechanical device. I learned this a long time ago by putting a robot through a door-frame at max speed. Edit: To add to this in a way that might actually make it useful to someone, motor outputs should almost always be a continuous function of something rather than their own internal state. MCAS should have been cod…

PID controls do exactly what you are objecting to.

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

#110
post #89

I believe the relative ease — not to mention the lack of tangible cost — of software updates has created a cultural laziness within the software engineering community. -- This --^ As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. I know folks here will deride me for being "inefficient", but in the long term I still maintain from my experience…

> As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. Do you use formal methods to prove the correctness of your code? Because that is what Boeing engineers do (I hope).

[deleted]
Post reply on HN