How the Boeing 737 Max disaster looks to a software Developer • Hacker News Board

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

#241

Post by masklinn » Fri, Apr 19, 2019, 6:34 AM UTC

ReGenGen wrote: post #62

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

The failures were first political, second managerial, and third ethical. The actual engineering failure is a far fourth.

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

#242

Post by tigershark » Fri, Apr 19, 2019, 6:38 AM UTC

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.

Or, you know, you don’t put engines way too big for your frame.

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

#243

Post by ReGenGen » Fri, Apr 19, 2019, 6:56 AM UTC

cyphar wrote: post #229

ReGenGen wrote: post #182

Earlier quoted context omitted.

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.

The article is making the point that the MAX is inherently unstable because of the larger engines causing the "pitch up" problem with an increasing angle-of-attack: > Pitch changes with increasing angle of attack, however, are quite another thing. An airplane approaching an aerodynamic stall cannot, under any circumstances, have a tendency to go further into the stall. This is called “dynamic instability,” and the on…

There are several respected industry professionals that believe the MAX is inherently unstable (and maybe they have insider information...) but this is not considered "fact" right now. (AFAIK)

MCAS was needed to maintain original 737 type specification which allows 737 pilots to fly any 737... significant operational flexibility & cost savings for airlines.

Commentary from blancolirio who is a current 777 pilot. https://www.youtube.com/watch?v=zGM0V7zEKEQ&t=0s

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

#244

Post by crimsonalucard » Fri, Apr 19, 2019, 6:56 AM UTC

throwaway2048 wrote: post #216

crimsonalucard wrote: post #215

Earlier quoted context omitted.

That's what I'm arguing. Code can be proven correct against a formal spec. However, because we don't do proofs in software, there are bugs.

Code is itself a specification.

It can be, but generally it is not.

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

#245

Post by PaulAJ » Fri, Apr 19, 2019, 7:07 AM UTC

One issue about the "bitey dog" MCAS not mentioned was the story of Air France 447 (https://en.wikipedia.org/wiki/Air_France_Flight_447). Thats the one that stalled into the Atlantic in 2009. The flight crew plus a pilot that was riding in the back seat spent minutes trying to debug the flight computer, and only realised too late that the copilot was pulling back on the stick the whole time, keeping the aircraft stalled.

This happened because of mode confusion: the aircraft computer realised it had compromised sensors and had switched to "alternate law", in which the computer would not override a stall. I have no doubt that Boeing knew about this incident and did not want to create a repeat.

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

#246

Post by cyphar » Fri, Apr 19, 2019, 7:14 AM UTC

ReGenGen wrote: post #243

cyphar wrote: post #229

Earlier quoted context omitted.

The article is making the point that the MAX is inherently unstable because of the larger engines causing the "pitch up" problem with an increasing angle-of-attack: > Pitch changes with increasing angle of attack, however, are quite another thing. An airplane approaching an aerodynamic stall cannot, under any circumstances, have a tendency to go further into the stall. This is called “dynamic instability,” and the on…

There are several respected industry professionals that believe the MAX is inherently unstable (and maybe they have insider information...) but this is not considered "fact" right now. (AFAIK) MCAS was needed to maintain original 737 type specification which allows 737 pilots to fly any 737... significant operational flexibility & cost savings for airlines. Commentary from blancolirio who is a current 777 pilot. http…

I'm not in any way an authority when it comes to aeroplanes.

However, my understanding is that the reason why MCAS was needed to maintain the original 737 specification is because of the "pitch up" behaviour on increased AOA (which is what is being described as "dynamic instability" in TFA).

The video you linked doesn't disagree with this -- though it's phrased as being primarily there to "replicate the same feel as earlier versions of the 737, by giving a little bit of nose-down trim". The article claims that being dynamically unstable means that at high-AOA you get nose-up lift (I'm not a pilot or aeronautics expert, so this might be an incorrect definition -- but I've not seen anyone disputing that definition nor disputing it's against FAA guidelines).

If you need an additional system to "replicate the feel" of not having nose-up lift at high-AOA that tells me that your plane design must therefore have nose-up lift at high-AOA. The guy in the video then goes on to say that it's an inherently stable design, but he doesn't really qualify it (other than saying that all other 737s are stable designs) and goes on to say that "the nose goes a little bit light".

Obviously we should hold back judgement until we know all the facts, but "the 737 MAX is an inherently stable design" is not someone holding back judgement.

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

#247

Post by tigershark » Fri, Apr 19, 2019, 7:37 AM UTC

WalterBright wrote: post #58

_bxg1 wrote: post #36

"Various hacks (as we would call them in the software industry) were developed." Dear God. That's a sentence I never, ever wanted to hear about an aircraft.

All engineering designs are full of compromises (the article uses "hacks" meaning compromises), as there are a large number of competing issues at work. Pretty much none of those issues are ever aligned along the same axis. For just a taste of this, an airliner flies at high altitude, and at low altitude. It flies at low speeds, and high speeds. It flies heavily loaded and empty. Optimizing for any one of these regim…

No, MCAS was absolutely not a compromise. It was definitely a hack to avoid the pilots recertification on a plane that would have handled differently from the previous model. And it was a hack put in place to correct for the other hack of moving forward the engines, that are way too big for that frame, and that caused the different handling. The only compromise that we can see is that safety was effectively compromised causing the death of hundreds of people just to avoid the pilot recertifications with their hacks.

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

#248

Post by TheOtherHobbes » Fri, Apr 19, 2019, 7:47 AM UTC

ReGenGen wrote: post #235

tristanstcyr wrote: post #202

Earlier quoted context omitted.

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 i…

If you're an engineering-led company, putting MBAs in charge of it will kill it - and probably a lot of other people too.

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

#249

Post by reacweb » Fri, Apr 19, 2019, 7:56 AM UTC

ncmncm wrote: post #156

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…

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.

I think the blame shall be entirely on the management of Boeing. The engineering details are mainly a plea against management.

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

#250

Post by antris » Fri, Apr 19, 2019, 7:59 AM UTC

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.

You don't cover edge cases mainly by writing specific code for everything and adding on to the existing load. You do it mainly by creating an elegant single solution that covers all cases. Every line of code and every technical layer you add makes you susceptible to even more bugs and edge cases.

And just because the airline industry does software backwards, doesn't mean that you should do so.