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

#271

Post by pps43 » Fri, Apr 19, 2019, 12:53 PM UTC

yason wrote: post #253

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.

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

You are referring to thrust asymmetry, not dynamic stability. Thrust asymmetry is actually not that different between MAX 8 and NG. MAX 8 engines have more thrust, but they are also mounted higher (closer to the centerline), reducing torque.

Dynamic stability is a tendency of the plane that flies straight and level to maintain this straight and level flight. MAX 8 still has this property, MCAS or not.

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

#272

Post by tlc1970 » Fri, Apr 19, 2019, 1:10 PM UTC

Frankly, as a traveler, I have lost trust in Boeing, the FAA, and the airlines.

This article underscores my concerns that the 737 Max was rushed to the market too quickly, and that there was an unacceptable delay in grounding these planes after two crashes.

The expertise of the airline and software industries is world class. However, the process by which a determination was made to consider the Max 737 safe has failed us as travelers.

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

#273

Post by tlc1970 » Fri, Apr 19, 2019, 1:23 PM UTC

This article increases my concern that the primary issue here is a failure in process to ensure the safety of passengers before the 737 Max went to market.

We have world class expertise in the aviation industry, and there is no excuse for rushing a product to market without fully vetting it for safety.

Boeing, the FAA, and the airlines moved too quickly to place the 737 Max in the air and too slowly to ground the planes after the second crash. In both cases it appears that these decisions were influenced by an over-reliance on the capabilities of technology over people.

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

#274

Post by crimsonalucard » Fri, Apr 19, 2019, 1:41 PM UTC

WalterBright wrote: post #22

crimsonalucard wrote: post #2

The irony of software is that it is the only discipline in engineering where results can be proven with logic. Yet we still do testing on it as if it was a blackbox.

Proving that software matches the spec is one thing, proving that the spec is free of bugs is quite another.

Yes. But for critical software systems, what excuse does one have not to prove that the software does not match the spec. There is no excuse not to test the spec, but what excuse is there not to prove the software?

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

#275

Post by kadendogthing » Fri, Apr 19, 2019, 1:44 PM UTC

bronson wrote: post #219

kadendogthing wrote: post #197

Earlier quoted context omitted.

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

You’re saying that Boeing intentionally sold unsafe airplanes? And the airlines, knowing this, still bought them?

I'm giving money to the airlines. Not Boeing.

>You’re saying that Boeing intentionally sold unsafe airplanes?

Yes.

>And the airlines, knowing this

You know airlines have their own engineering teams, right? And they were bought explicitly to save money.

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

#276

Post by bumby » Fri, Apr 19, 2019, 1:51 PM UTC

linuxftw wrote: post #193

bumby wrote: post #164

Earlier quoted context omitted.

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

I have no clue about Boeing's staffing practices but it's often the case in large organizations that the people trying to prudently hold up a project because it's not ready are looked at less favorably by those with "go-fever".

I agree they should be held accountable but there's also blowback from bankrupting one of a nation's major aerospace manufacturers

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

#277

Post by siwatanejo » Fri, Apr 19, 2019, 2:27 PM UTC

fogetti wrote: post #261

Let me tell one thing: I absolutely hate sloppy engineering. And by sloppy I also mean rushing. There is a class of engineers and engineering managers who think that they are rockstars because they can churn out code quickly. I am absolutely disgusted and sick of this attitude. And why do I bring it up here? Because I suspect this kind of attitude was partly blamed for this fatal and tragic accident. Of course this i…

Completely agree.

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

#278

Post by [deleted] » Fri, Apr 19, 2019, 2:43 PM UTC

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

#279

Post by HankB99 » Fri, Apr 19, 2019, 2:57 PM UTC

ncmncm wrote: post #91

leoedin wrote: post #26

Earlier quoted context omitted.

I don't think it does. Other sources I've read suggest the larger nacelle introduces a pitch up during certain flap configurations and at a high angle of attack. It's not the engine thrust that's the problem, but the drag due to the large and further forward nacelle. That's the justification for the MCAS software. https://theaircurrent.com/aviation-safety/what-is-the-boeing...

It's both. The engine thrust center is also farther below the center of pressure of the airframe. And it can apply a lot more thrust than the original engines. The point about lift from the engine nacelles was that it acts as positive feedback: if you are already pitched too high, it acts to worsen the problem. And, because it is farther forward, it has a greater lever arm to act.

Thanks, Those factors make sense.

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

#280

Post by mch82 » Fri, Apr 19, 2019, 3:17 PM UTC

adreamingsoul wrote: post #92

Something that stood out to me in this article was the author's opinion of how software developers are removed from the subject matter. From my experience I tend to agree but I hope we can change this. For context, I'm a software engineer and designer with a UX focus. As part of my process to design a system, interface, feature, or fix I first immerse myself into the world of the person who is using the software. Wha…

You’re asking great questions. Keep fighting for the time you need to answer them. I’m 13 years out of college & my perception is companies care more about stakeholder research than they did when I started working, so I think the overall trend is better.