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

231–240 of 306 posts

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

#231

Post by halter73 »

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.

I heard the MCAS was required to avoid a situation where the MAX, after reaching a certain pitch, would continue pitch up into a stall even if both pilots released the yoke. I don't know if that's considered "inherently unstable", but this is against FAA regulations for any commercial airplane from what I heard. That's probably a big reason why Boeing made it so difficult to completely disable the MCAS system.

My understanding is that MCAS altered fight characteristics not only to match older 737s and avoid additional pilot training. MCAS altered fight characteristics so the FAA would approve the MAX as a commercial aircraft period. The fact they could match older 737s flight characteristics for a more speedy approval from the FAA was just gravy.

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

#232

Post by metanoia »

Cacti wrote: post #179
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…

Stab trim cutout is not the only way to disable MCAS. Extending the flaps any amount also disables MCAS. Turning on autopilot also disables MCAS, though this isn’t entirely effective since spurious AoA readings may quickly disable the autopilot again.

One question I've had is why Boeing changed the design of the stab cutout switches from the 737NG from a pair of switches - the right side switch that disabled the autopilot control of trim and the left side that disabled the trim motors entirely [1] - to a design with a similar pair of switches, but each controlling the primary and backup control motors of the elevator trim [2] instead of controlling the source of the input. (If you look closely at the yoke trim switches, there are two independent switches that are grouped together by a frame so that they move simultaneously. One drives the primary motor, and the other the secondary).

Assuming they'd kept MCAS on the switch associated with the automatics, the procedure would have been to throw the AUTO PILOT switch, disabling MCAS, but keeping the MAIN ELEC switch on, allowing them to trim back to neutral for that speed.

[1] https://www.airliners.net/photo/Australia-Air-Force/Boeing-7...

[2] http://www.b737.org.uk/mcas.htm#stcs

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

#233

Post by Jonnax »

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 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.

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

#234

Post by Gibbon1 »

alacombe wrote: post #66
rubicon33 wrote: post #55

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.

I think that 'can safely ship' is primary feature of any software project. What the means in practice is it puts pressure on new features and 'refactoring'

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

#235

Post by ReGenGen »

tristanstcyr wrote: post #202
ncmncm wrote: post #162

Earlier quoted context omitted.

Of course, that much engineering failure is not possible without even more management and regulatory failure. But documenting the engineering failures is necessary to quantify the management failures, at least until discovery in the wrongful-death lawsuits begins.

I find that engineering vs management is not a very useful discussion point. Management is composed of engineers too and engineers are responsible for the output of their work. Production of something that doesn't work is an engineering failure. It's depressing that everyone went along with this. Clearly there's a lack of impartial checks and balances in the process.

I believe Boeing's shift from an "Engineering Culture" to a "Corporate Political Culture" is the root of the issue. https://www.seattletimes.com/business/boeing-aerospace/book-... https://www.forbes.com/sites/stevedenning/2013/01/21/what-we...

Boeing executives shifted focus from engineering to cost-cutting, outsourcing, and moving production & HQ to gain political influence. Moving Corporate HQ from Seattle was to insulate executives from engineering and increase political leverage in DC.

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

#236

Post by Gibbon1 »

Retric wrote: post #101
baddox wrote: post #94

Earlier quoted context omitted.

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.

I wrote a buggy POS test program that had race conditions because I didn't really understand what I was doing. And sometimes it would assign two units the same serial number. It would check once the test was done and just fail one of the two if that happened. And the tech would just rerun the test on that unit.

In the big scheme of things no one cared.

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

#237

Post by jrockway »

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.

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

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

#238

Post by Gibbon1 »

WalterBright wrote: post #97
_bxg1 wrote: post #73

Earlier quoted context omitted.

I don't even work on life-or-death machinery, only JavaScript UI's, but if a higher-up requested a new feature from me that would require multiple cascading changes just to keep other things from breaking, I would fight tooth and nail to talk them out of it. The compromises you're talking about are fundamentally unavoidable ones that come directly from the constraints at hand. A hack is something that degrades the in…

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…

> "multiple cascading changes"

That's aircraft in a nutshell. I read a book on light aircraft design by a now long dead professor[2]. He had a penciled out analysis of what would happen to a 2 seater light plane if you replaced the simple and light stick with cables design[1] with a hydraulic one. Only added about 40lbs more weigh. Or 300lbs when that was propagated through the design. And needed a bigger engine.

[1] Control surfaces operated by a system of cables and pulleys controlled by a stick.

[2] KD Wood https://en.wikipedia.org/wiki/Karl_Dawson_Wood

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

#239

Post by ralph84 »

jussij wrote: post #220
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 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…

The flying public will buy the cheapest ticket, same as always.

This isn't even the first time a design flaw leading to loss of control has crashed multiple 737s.

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

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

#240

Post by masklinn »

1v1id wrote: post #160
m463 wrote: post #157

Earlier quoted context omitted.

I don't know, I think the 3 points in the article make it glaringly obvious that the root cause is NOT engineering. The decisions made clearly ignored engineering and historical precedent at every turn. It's sad because Boeing has had some wonderful engineers, and Boeing aircraft have traditionally allowed the pilots to have the final say.

> 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.

The engineering blame is that they couldn't engineer themselves out of a political problem. I wouldn't call that "engineering blame".

Deep ethical failure, maybe, but this here place usually has a hard-on for epically failing the most basic ethical non-challenges.

Post reply on HN