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

91–100 of 306 posts

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

#91

Post by ncmncm »

leoedin wrote: post #26
HankB99 wrote: post #17

I'm unclear on how moving the engine up causes application of power to cause the attitude to tend to go nose up. I would expect the opposite to happen. I think something else must have changed such as the center line of the engine relative to the center line of the plane. Or did moving the engine forward at the same time cause this effect?

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.

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

#92

Post by adreamingsoul »

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.

What's the environment that these people are working in? What are their motivations and frustrations? What allows them to be successful in their job?

Over the last couple of years I've had less and less time to answer those questions. Either because of a high workload or because management didn't see the value in spending time to research the people using our software. That trend is alarming and concerning to me. If we as software engineers are not aware of the people who are using our software, how are we solving the right problems?

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

#93

Post by ReGenGen »

mfer wrote: post #79
cjbprime wrote: post #72

Earlier quoted context omitted.

Yeah, maybe also some Boeing/Airbus confusion. The author doesn't seem to understand the extent to which the 737 cockpit is mechanical, with cables running to control surfaces. It's an important point because it likely explains why the Ethiopian pilots were unable to regain control after disabling electric trim, becoming overpowered by aerodynamic load on the stabilizer.

In newer 737 versions it's no longer cables... http://www.boeing.com/commercial/aeromagazine/aero_02/texton...

FYI That doc is about "Propulsion Control Systems" not elevator trim or control surfaces.

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

#94

Post by baddox »

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…

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.

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

#95

Post by Frost1x »

winrid wrote: post #60
rubicon33 wrote: post #55

Earlier quoted context omitted.

If only managers and CEOs saw it the same way.

At my current company all leadership is in agreement that it is more expensive to deal with bugs in production.

But CD...agile...

It really depends on the scenario. If you can bill those fixes to the client or if you have to eat the cost to make the fixes. Most modern development processes seem to push this model simply because they can essentially pass the costs to the client and charge other or future clients for the improvements.

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

#96

Post by baddox »

rdiddly wrote: post #64
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…

The most efficient way to do it is to do it once.

That is definitely not true for all tasks, and especially not all software engineering tasks.

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

#97

Post by WalterBright »

_bxg1 wrote: post #73
WalterBright wrote: post #58

Earlier quoted context omitted.

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…

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

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

#98

Post by sisu2019 »

Sorry, I don't believe that our perspective on this is especially valuable or insightful. Everyone with an average IQ can explain in 5 sentences what went wrong with this plane. Yes new engines didn't fit the plane, fixed with software, well done.

But why? It's not profits. Boeing has been for profit from the start.

It's something more. We are getting bad at doing hard things. Here in Germany we can't seem to finish a new airport (BER). Or a new train station (Stuttgart 21). Or the new ICE trains. Or keep the autobahn bridges maintained.

And software? There is an article about problems with Win 10 updates ever day now it seems. And what about all these new SPA type websites that pull down 30 megs of javascript in order to keep failing at basic tasks in new and exciting ways? On latest android there is a packet fragmentation bug that has gone unfixed for 6 month and counting now. Oh it only prevents people from using amazon and netflix so no big deal.

I grew in a time where we expected stuff to get better and better but lately it seems we'd do well to just hang on to what we have.

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

#99

Post by scrape_it »

mongol wrote: post #70
scrape_it wrote: post #28

Earlier quoted context omitted.

huh? interesting, do you have more info, I love reading stuff like this. I don't know much about the Gripen but it is my all time favorite after the F-16. Off topic but here's a neat youtube video of Gripen jets undergoing rapid turn-around, on a normal street road with just a handful of people, and special tools for the crew: https://www.youtube.com/watch?v=49L9BlYQSjw

The first crash: https://www.youtube.com/watch?v=k6yVU_yYtEc Second crash (over middle of Stockholm) https://youtu.be/mkgShfxTzmo?t=133 From Wikipedia: During the test programme, concern surfaced about the aircraft's avionics, specifically the fly-by-wire flight control system (FCS), and the relaxed stability design. On 2 February 1989, this issue led to the crash of the prototype during an attempted landing at Linkö…

can't believe the first one didn't result in a ball of fire...

the second was even more shocking, all of a sudden it looked like he was trying a Cobra maneuver until he ejected! that's insane.

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

#100

Post by WalterBright »

ken wrote: post #77
WalterBright wrote: post #65

Earlier quoted context omitted.

You'll see it in any piece of software written by any developer who is self-managed. The notion that software quality would greatly improve without managers is a myth.

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.

If you were your own manager for your own code, you'd do it to. I'm unaware of any data showing managed software development is buggier than programmers working by themselves, and my experience is it is less buggy.

Programmers by default tend to want to work on the fun stuff in a program, and neglect the unfun pedestrian stuff. This is where managers step in to improve things.

Post reply on HN