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

141–150 of 306 posts

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

#141

Post by kakwa_ »

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 is avoidable, something is at least a bit wrong. A few hacks like that are manageable, but too many, and you dramatically increase the chances of one of these hacks misbehaving.

And if an organization is pushing a lot for this kind of hacks as Boeing did, the issue is not even technical.

The story of MCAS reminds me a little about the MD11. The DC10 as a tri-jet could not really compete with new dual engine airplanes in the late 80ies/early 90ies in term of fuel consumption, but McDonell Douglas try to anyway. They optimized the wings, change the engines, add winglets and more significantly reduce the horizontal stabilizer size. This made the MD11 quite hard to land as it needed to go-in with a very high speed for a wide body jet. It was a contributing factor in several accidents (Fedex 14, Fedex 80, Lufthansa Cargo 8460), and pilot training/technical fixes never fully compensate for the design flaw. And in the end, the aircraft kind of failed to reach the target fuel consumption. However, it's still flying today, and it's still a workhorse for cargo companies.

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

#142

Post by Sharlin »

_bxg1 wrote: post #126
Sharlin wrote: post #125

Earlier quoted context omitted.

> What if the domain experts could not only speak the language of code, but could do some of the coding themselves? Some can, especially in the academia. It… sort of works but is certainly not optimal. The truth is, it is not enough to be a coder who knows something about the domain, and neither is it enough to be a domain expert who can code. You have to be an expert at both, like the author of TFA. Or at the very l…

Could there not be domain experts who know how to express their general ideas in terms of code (pseudocode, even), paired with coding experts who can architect the overall software system? You'd still need software experts, but you wouldn't have just software experts.

Yes, as I said: teams are a superorganism, a force multiplier. But a team of coders isn't enough, you need a close-knit team of people with diverse areas of expertise, and those people need to be great at communicating.

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

#143

Post by WalterBright »

rubicon33 wrote: post #118
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.

It's the artificial timeline, not the manager. The manager just enforces the artificial timeline. A developer themselves can hold themselves to an artificial timeline. It takes discipline, and patience, to choose quality over speed to market. CEOs and managers almost always prioritize time to market, over quality. That's the problem.

Most projects (not just software) never ship unless there's a deadline. For example, how many students complete their term papers weeks before they're due? If there was no due date, how many would ever complete them? I know I never would have learned much of anything in college without deadlines and exams.

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

#144

Post by mcny »

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…

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

I think the charges people are bringing is that Boeing wanted to make the new airplane acceptable by airliners by making the 737 Max the same as the old plane so there was no need to certify pilots for the new plane. My vote is that this is criminal negligence at best and under an ideal government, the then CEO and board would be in jail pending charges right now.

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

#145

Post by zestyping »

bollu wrote: post #5
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.

I'm not sure you understand how difficult it is to prove software correct. I've written a decent amount of Coq code. It's quite bonkers how much of proof one needs to write to get anything done. For reference, the certified compiler CompCert's code base is something like 10% code and 90% proofs.

If the proof is more complex than the software, I don't see how that gains you anything. It's harder to verify that you've proved the right thing than to verify the software itself, so how does that help?

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

#146

Post by DuskStar »

This article reads well. Unfortunately, it's filled with fundamental mistakes.

> In the old days, when cables connected the pilot’s controls to the flying surfaces, you had to pull up, hard, if the airplane was trimmed to descend. You had to push, hard, if the airplane was trimmed to ascend. With computer oversight there is a loss of natural sense in the controls. In the 737 Max, there is no real “natural feel.”

Whoops. The 737 is one of the few airliners produced today that DOES still directly connect the pilot's controls to flying surfaces. There's literally 12mm wires connecting the yoke to the control surfaces. So, in fact, the 737 does have "natural feel". In fact, that's the whole problem MCAS was designed to solve - how to add force to the yoke when at high AOA in certain speed regions, in order to ensure a linear AOA response. (Certification requires something along the lines of "5 pounds force -> 5 degree AOA, 10 pounds force -> 10 degree AOA, etc") If the 737 was fly-by-wire, this force could be added directly in software. Instead, they added this force by changing the aircraft's trim.

> In a pinch, a human pilot could just look out the windshield to confirm visually and directly that, no, the aircraft is not pitched up dangerously.

No, you can't. There isn't a visual indication for AOA - the author is confusing this with pitch. You can have a 45 degree AOA while still having the nose of the plane pointed at the horizon. (The author mentions using the artificial horizon for this purpose, too) If you could read AOA from sensors that didn't require being exposed to the airflow, planes would use them.

I'm sure there's more, and it greatly reduces my confidence in the article.

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

#147

Post by _bxg1 »

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…

This is true, but any number of engineers still should have blown the whistle. The driving force may have been managerial greed, but other factors still could have averted it.

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

#148

Post by mathgenius »

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…

This was not buggy software. This was a bad specification. The software did what it was supposed to do.

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

#149

Post by WalterBright »

LordHog wrote: post #83
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.

In the various industries I have worked in DO-178B, industrial controls/IEC-61508, and storage the one consistency shared by managers is meeting schedules and milestones. Generally, a manager's insight to development/engineering is for the product to be just good enough. Developers/engineers have a tendency to over engineer the solution. Good peer reviews have the most influence on software quality as does independen…

Businesses would not employ expensive managers if the dev teams worked better without them.

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

#150

Post by rubicon33 »

WalterBright wrote: post #143
rubicon33 wrote: post #118

Earlier quoted context omitted.

It's the artificial timeline, not the manager. The manager just enforces the artificial timeline. A developer themselves can hold themselves to an artificial timeline. It takes discipline, and patience, to choose quality over speed to market. CEOs and managers almost always prioritize time to market, over quality. That's the problem.

Most projects (not just software) never ship unless there's a deadline. For example, how many students complete their term papers weeks before they're due? If there was no due date, how many would ever complete them? I know I never would have learned much of anything in college without deadlines and exams.

Of course. I'm not advocating for no deadlines. I'm advocating for flexibility.

If your deadline arrives and you can honestly say you've worked hard but haven't met it, consider extending the deadline in the name of quality.

Again, this takes discipline. You have to be honest with yourself if you are just moving the deadline back because you were slacking. In my case many times, the deadline was not hit because the scope of the project was underestimated. We were working hard on a new technology stack, but missed the deadline. Rather than delay the product, CEO decided to launch (despite our warnings).

Needless to say, the brand suffered.

I understand its a tug of war. Managers need to put out something. Engineers are never ready. The art in it all, is finding the balance. Being flexible to listen to your engineers, and knowing them well enough to trust them.

Post reply on HN