Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

191–200 of 306 posts

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

#191
post #77

Earlier quoted context omitted.

We seem to have very different experiences. Every manager I ever had (including one at Boeing) has pushed me to ship software that wasn't at all ready, on the basis that the UI of the prototype looked good.

I am terrified these days of showing anything that looks like something that works to a project manager or client, without covering it in warning graphics. Even photoshop mockups of UIs, introduced as, "Here's a photoshop mockup of the UI, what do you think?" will get some people to demand that it be shipped immediately.

One thing that I've learned (from someone else) is that unfinished software should look unfinished. Even if you have to muck around with CSS, disable some buttons here and there, maybe add something out of place.

If the UI looks perfect, then everyone will deem it to be finished, even people who should know better.

Yes, I'm advocating knowingly crippling demos. Your master branch may have something prettier, but take a sledgehammer and uglify the bastard before showing to decision makers.

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

#192
post #71

>Unfortunately, the current implementation of MCAS denies that sovereignty. It denies the pilots the ability to respond to what’s before their own eyes. >In the MCAS system, the flight management computer is blind to any other evidence that it is wrong, including what the pilot sees with his own eyes and what he does when he desperately tries to pull back on the robotic control columns that are biting him, and his pa…

Well, no robotic control columns, but the effect of silently adding uncommanded trim is the same.

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

#193
post #164
post #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…

I agree that people often seem to miss that this may be rooted in a business decision. The problem is it isn't a risk-informed decision. I would doubt Boeing was accurately able to assess the actual risk of MCAS causing a catastrophic failure or else the decision to rush to market wouldn't have happened. I think just as large of a problem is mis-aligned incentives. Management is almost assuredly not singly focus on t…

> I would doubt Boeing was accurately able to assess the actual risk of MCAS causing a catastrophic failure or else the decision to rush to market wouldn't have happened.

That's most likely because upper management has been cutting staff and not investing in their people.

They should be sued and fined out of business. Whoever picks up the pieces will know: "Don't cut corners, or it's absolutely ruins."

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

#194
post #178

This article reads well. Unfortunately, it's filled with fundamental mistakes. > In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.” Whoo…

> No, you can't. There isn't a visual indication for AOA - the author is confusing this with pitch. You can have a 45 degree AOA while still having the nose of the plane pointed at the horizon. (The author mentions using the artificial horizon for this purpose, too) If you could read AOA from sensors that didn't require being exposed to the airflow, planes would use them. I think you may have missed the context of th…

I wouldn't say that you can't correctly diagnose the failed AOA sensor in the majority of cases, but the conditionals to disable a safety system are probably going to have to be more rigorous than "AOA changing between extremes without significant change in pitch, airspeed or altitude". Just for starters, imagine you've hit a particularly violent updraft and then a downdraft... Though I'm not sure if such weather conditions would exist anywhere you'd plan to fly an airliner.

(And I'm kind of being "perfect is the enemy of good" here, sorry. Any "AOA sensor is wonky, disable MCAS" methodology would probably have resulted in better outcomes than the one they used. It's just that none of them are really perfect)

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

#195
post #144

Earlier quoted context omitted.

They're the same thing. BTW, many aircraft crashes were due to a pilot doing what would have been the right thing on another design they were familiar with. Boeing's plan to make the MAX behave like other airplanes is a reasonable plan to improve safety. The "multiple cascading changes" is always an issue with a complex design, and in fact Boeing's approach with the Max was choosing a route which minimized those casc…

» They're the same thing. BTW, many aircraft crashes were due to a pilot doing what would have been the right thing on another design they were familiar with. Boeing's plan to make the MAX behave like other airplanes is a reasonable plan to improve safety. » The "multiple cascading changes" is always an issue with a complex design, and in fact Boeing's approach with the Max was choosing a route which minimized those…

You wouldn't have any planes (trains or automobiles) under such a standard. Keep in mind that horses killed far more people per mile than planes, trains or automobiles ever did.

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

#196

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.

This appears to be what happpened.

If so, it amounts to criminal negligence. People should go to jail, but if anybody does, it will certainly not be the ones ultimately responsible. Most likely Boeing will pay fines and court judgments, something probably already factored into their stock price, impacting people holding the stock this year, not those who might have demanded better management five years ago.

Certainly the whole top tier of management should be fired, but that won't happen either.

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

#197
post #183
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.

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

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

#198

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…

This was not buggy software. This was a bad specification. The software did what it was supposed to do.

Anyway, specified to do.

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

#199

Earlier quoted context omitted.

Code cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.

I guess that was a poorly chosen word on my part then. How about 'elegant'.

"Elegant" does't mean "right" either.

But with elegant code it is often easier to tell if it's not right, and also how to get it right if it's not. Often that requires making it less elegant, because the real world rarely poses elegant problems. You want to ensure that as much as possible of the necessary inelegance is at the top level, with everything below clean.

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

#200

Could someone please ELI5 what exactly went wrong that caused the crash? I read the article but I still don't understand if the crash was caused by (a) The MCAS doing something it wasn't programmed to do (by specification) (b) MCAS was working as expected, but the expectations/assumptions were wrong (excluding pilot mistakes). (c) MCAS worked as designed, and the design was correct IF the pilots behaved like Boeing e…

The answer is B.
Post reply on HN