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

251–260 of 306 posts

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

#251

Post by kakwa_ »

jrockway wrote: post #237
Jonnax wrote: post #233

Earlier quoted context omitted.

Will it fly? I think we live in a different world now. The 737 MAX via social media has a perception of being a "Boeing death plane" Public opinion could ground it.

The DC-10 did fine after its rough start. It's still flying today.

That's also the interesting part.

The DC-10 ended-up being a reliable airplane, but its early crashes damaged its reputation heavily, and the handling of these issues by MD was poor.

Commercially, MD never completely recover, and was absorbed by Boeing in the 90ies. (To be honest, it's not the only factor, you have also the L1011 competition and the fact a trijet was somewhat of an evolutionary dead end).

Boeing is much larger, and much stronger it can probably cope with it, but it will be a hit on their best selling aircraft. It's basically the 737 that finances the new 777 or 787, costly programs not certain to recoup design costs (same with Airbus, the A320 is basically financing the A380 failure). At the same time, part of the 737 market is a bit captive with the biggest low cost companies (Southwest, RyanAir) using it unlikely to switch.

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

#252

Post by [deleted] »

amluto wrote: post #109
AWildC182 wrote: post #90

Earlier quoted context omitted.

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.

[deleted]

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

#253

Post by yason »

ReGenGen wrote: post #182
1v1id wrote: post #160

Earlier quoted context omitted.

> So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail .... Big strike No. 3. The article definitely does partially blame engineering.

We don't know the MAX is inherently unstable. That's still conjecture at this point. MCAS may have altered fight characteristics to match older 737 to avoid additional pilot training. If the MAX is inherently unstable, then this scandal is much bigger and far reaching.

But wasn't this explained in the article, already. Dynamically stable plane doesn't aggressively rotate along any of its axis, for example, when you increase or decrease throttle. The location of MAX engines generates additional forces to increase pitch when engine power is increased, and even more so when the plane is already pitched high. Earlier 737's could do without MCAS because they were designed with smaller engines in lower locations in order to be dynamically stable.

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

#254

Post by acqq »

ncmncm wrote: post #167
acqq wrote: post #139

Earlier quoted context omitted.

> A sixth was that, besides comparing redundant sensors, it could have compared what the other flight computer thought it should be doing. If you mean AoA sensors, AFAIK, there was absolutely no redundancy at all the way MCAS was designed. Exactly one sensor was ever used for MCAS. And last time I've read the Boeing's reported coming software changes, they wanted to keep it so, but just to add the notification to the…

Comparing sensors and comparing judgment of the other computer were both things they could have done, that they utterly failed to do, in both cases.

Because their main premise was that they are selling the "same old" plane, and any change in any workflow would make obvious it is not.

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

#255

Post by tremon »

anbop wrote: post #113
rkagerer wrote: post #49

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…

Well, great code is inefficient if the impact of bad code is minimal. If you are shipping an animated emoji you should be sloppier with your code than if you are building flight control software. Overengineering software is like over-specing building materials by 10x and spending way more money on a building than it needs.

And in that same line of argument, great code is inefficient if the bad code can always be fixed post-release.

Never mind the consequences of the first release, if we sell enough of it we might be bothered to pick up our slack 2 years from now.

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

#256

Post by tremon »

underwater wrote: post #174
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…

If the only gatekeeper against shipping bugs is a senior engineer catching bugs in review, then that's possibly a sign that your processes need improvement, rather than the people.

Not rather; in addition to would be more appropriate.

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

#257

Post by kakwa_ »

throw7 wrote: post #190
kakwa_ wrote: post #141

Earlier quoted context omitted.

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…

I'm confused with your response. So nothing to see here? Nothing to learn and change? You seem to say we should accept design flaws (like we did with the MD11?)... correct? Or?

Basically yes. The airlines learnt to mitigate the risks associated with the design, and there were a few small modifications (light indicator to detect bounced landing for example). There is a risk, but it's at acceptable level.

The fact is an airplane is a huge investment, made to last 20, 30 and in some cases even 40 years (not necessarily with the same owner). You cannot exactly throw it away and buy a new one even if it has defects. At most, it ends-up lasting a bit less (ex: 15 years instead of 20 years) or is relegated to a specific usage where the consequences of failures are less dramatic (ex: freight).

There are still 20/25 years old airplanes flying with passenger, which are inherently less safe than (properly designed) new airplanes because of their age and their avionics. Yet there are still flying.

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

#258

Post by LandR »

Jonnax wrote: post #233
kakwa_ wrote: post #141

Earlier quoted context omitted.

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 it fly? I think we live in a different world now. The 737 MAX via social media has a perception of being a "Boeing death plane" Public opinion could ground it.

From the people I've spoken to about this, I'd say less than half even know that the 737Max is a thing, never mind that it's crashed twice.

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

#259

Post by [deleted] »

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.

[deleted]

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

#260

Post by ulfw »

Cacti wrote: post #186
kakwa_ wrote: post #141

Earlier quoted context omitted.

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…

There are thousands of “hacks” like this in every modern airliner. That’s how complicated problems are solved, you come up with a basic idea, and you iterate on it thousands of times until you squash all the edges cases.

There really aren't. Please don't state opinion as fact. There aren't "thousands" of "hacks" to make an airframe fly reliably. That is preposterous.
Post reply on HN