Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boeing's 737 Max software outsourced to lower-paid engineers

bloomberg.com

Post reply on HN
Print view View original

151–160 of 166 posts

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#151

Post by sokoloff »

dTal wrote: post #130
ganeshkrishnan wrote: post #87

Earlier quoted context omitted.

The software did exactly as it's supposed to do: If the AOA sensors tells you the plane is tilting too high up, pitch the nose down a little. The main issue was that there was only one AOA sensor connected in standard packages and the hardware for it failed. The pitot tubes failed for the doomed Air France incident which caused the software to read incorrectly and stall. For what it's worth AirBus has a huge engineer…

This comment is glib and misinformed. Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not supposed to do that. And your description of the MCAS specification is vastly over-simplified - it is not an autopilot and its job is to gradually change the behaviour of the plane in different flight modes (which it must detect), not to directly fly the plane…

Agree with everything you wrote, with the possible exception of referring to the stick-holder in the AF447 crash as a "pilot".

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#152

Post by AlexCoventry »

danielg6 wrote: post #117
AlexCoventry wrote: post #105

Earlier quoted context omitted.

> Articles like this are just drummed up to stir negative emotions about "others" The negativity seems more targeted at the leaders who arranged this than at the developers. Both the examples you cite are from the same comment, and even that comment is more about resentment towards management corruption than about the incompetence of the developers hired as a result of the corruption. > The software did exactly as it…

See the post below yours lol.

Not sure which one you were referring to. The ordering of comments changes over time. Could you post a URL or identifying substring?

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#153

Post by kahlonel »

tiredofit wrote: post #83
tiredofit wrote: post #34

Earlier quoted context omitted.

Software was definitely part of the issue.

But it wasn't a software issue! /S https://philip.greenspun.com/blog/2019/04/08/boeing-737-max-... Any competent engineer would raise moral and ethical questions when working on software that is "mission ciritical". Causing a passenger plane to continually go into a nose dive because of data coming from a single sensor is absolutely ludicrous. Just because the software was horribly designed, doesn't mean it isn't a s…

It is a hardware design issue. There's a concept of N+1 redundancy in safety-critical systems, a hardware design decision. This basic philosophy was missing from the MCAS system[1]. You can argue that the software could just ignore bad sensor readings, but that's just software making up for hardware deficiencies.

1. https://www.seattletimes.com/business/boeing-aerospace/a-lac...

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#155

Post by danielg6 »

AlexCoventry wrote: post #152
danielg6 wrote: post #117

Earlier quoted context omitted.

See the post below yours lol.

Not sure which one you were referring to. The ordering of comments changes over time. Could you post a URL or identifying substring?

That’s the joke... You can scroll up or down and find such a comment.

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#156

Post by nobodyandproud »

ganeshkrishnan wrote: post #135
nobodyandproud wrote: post #115

Earlier quoted context omitted.

The problem is that developers also need to understand what they are coding, and fight back when they notice that the design is fundamentally flawed. In this case, the lack of redundancy should have been a red-flagged. This is why domain knowledge is at least as important as coding skills.

There were multiple redundancy built in. Multiple sensors, voting mechanism, manual override. Many of which meant re-training the pilots and Boeing wanted to avoid it. I think southwest airlines had multiple sensors

The 737 Max aircrafts that crashed relied on a single AOA sensor.

A second AOA sensor is an option.

Which means code was written to account for both configurations.

Many, many things must happen and change to avoid allowing management to make decisions unchecked.

Because this is a case of bargain-bin engineering and tunnel-visioned management ruining a once-reputable company.

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#157

Post by [deleted] »

ganeshkrishnan wrote: post #135
nobodyandproud wrote: post #115

Earlier quoted context omitted.

The problem is that developers also need to understand what they are coding, and fight back when they notice that the design is fundamentally flawed. In this case, the lack of redundancy should have been a red-flagged. This is why domain knowledge is at least as important as coding skills.

There were multiple redundancy built in. Multiple sensors, voting mechanism, manual override. Many of which meant re-training the pilots and Boeing wanted to avoid it. I think southwest airlines had multiple sensors

[deleted]

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#158

Post by atpalmer »

ganeshkrishnan wrote: post #88
throwawayMUSE wrote: post #74

Earlier quoted context omitted.

I worked at a Fortune 10 in the early 2010s for several years. We had a small army of local and offshore Indian contractors through Larsen and Toubro Infotech, an Indian IT company. They were paid between $10-20 an hour, many couldn’t understand English. These guys have no CS background and would get stumped writing fizz buzz. But hey, management got ball game tickets and other favors from the L&TI reps. One of the d…

You must have been a pleasant employee to work with.

throwawayMUSE is clearly right. These firms are playing the same game as used car salesmen--selling you junk that won't make it off the lot, all for $9/hr. It's true even for non-critical .NET apps that the business is getting ripped off. In mission critical systems, it's literally life and death. Sounding the alarm doesn't warrant dismissive sarcasm.

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#159

Post by atpalmer »

la_barba wrote: post #41

I think this is just rabble-rousing. For all the flack outsourcing gets, if you hire an incompetent person, and they fuck up, you're still responsible for hiring an unqualified person. I don't think it matters if that person was outsourced or not. I haven't worked with any offshore teams, but friends tell me you can do what are called "client interviews" where the client, in this case Boeing, has the option of interv…

The article you just read told you that the teams working on critical software have to be cheap, not good. That's not "just rabble-rousing." That's a scandal.

As you say, you're commenting without having any experience with the issue, but, as you can imagine, there's very little overlap between cheap and good.

Re: Boeing's 737 Max software outsourced to lower-paid engineers

#160

Post by atpalmer »

usrusr wrote: post #57

Is that so surprising? I have never worked in a domain like that, but I have always assumed that flight computer software would be built with process so deep that you could almost leave the implementation to trained monkeys, implying that those $9/h workers could still be overqualified. In my mental model of this kind of development (which could be wrong), you'd absolutely not want the 10x hotshot coder, you'd want p…

Exactly what salawat said. The 10x coder isn't the "hotshot" type. They're 10x because they build systems well enough to deliver 10x the features, 10x the reliability, etc., etc.

What isn't well understood is that software is never fully spec-ed out. No matter how hard some businesses may try, only the coder is in the position to find corner cases, unspecified cases, cases that "shouldn't happen" (but can), and just bugs in the spec. It's unrealistic to build a quality system without a feedback loop between the people writing the spec and the people coding the spec. Both sides have to be smart and engaged.

There's certainly nothing wrong with the article. I didn't see it taking a point-of-view on who is and isn't to blame. It's telling factual information, which is relevant to the story of what happened, and you can make your own judgments.

Post reply on HN