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

81–90 of 306 posts

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

#81

Post by amluto »

One thing I really don’t get about MCAS: even disregarding all its bugs, it seems like a really awful style of envelope protection. I’m neither a pilot not an expert, but I can imagine several more reasonable strategies when the pilot pulls up too hard: ignore the problematic yoke input, offset the elevators a bit, or apply more force to the yoke. Moving the stabilizer out of trim seems totally wrong.

As an analogy: almost every car has envelope protection. But no car designer in their right mind would build an ABS system that responded to wheel lock by moving the brake pedal or loosening the master cylinder (and not putting it back!). Similarly, it would be crazy for a stability control system to counter oversteer by offsetting the steering wheel (and leaving it offset).

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

#82

Post by [deleted] »

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…

[deleted]

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

#83

Post by LordHog »

WalterBright wrote: post #65
rubicon33 wrote: post #55

Earlier quoted context omitted.

If only managers and CEOs saw it the same way.

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 independent testing. Managers rarely have little impact that I have witness over my 25 year career, thus far. For industries that adhere to DO-178B or IEC-61508 guidelines, it is the process that imbues greatly improved quality.

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

#84

Post by drewrv »

scrape_it wrote: post #11
crimsonalucard wrote: post #7

Earlier quoted context omitted.

No, I get it, but still... it's ironic. Software for a plane, though, I would want 1% code 99% proofs.

Well, to support the top parent's comment, here's what John Carmack had to say about SAAB's fighter jet: > The fly-by-wire flight software for the Saab Gripen (a lightweight fighter) went a step further. It disallowed both subroutine calls and backward branches, except for the one at the bottom of the main loop. Control flow went forward only. Sometimes one piece of code had to leave a note for a later piece telling…

What saves Airbus is the extra MCAS system, and a stronger regulatory environment, and most importantly a jet that has the engines mounted in the proper place so it doesn't have a tendency to stall.

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

#85

Post by atoav »

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.

Which leads to the heart of the discourse: programming is many things at once. Programming a single purpose library or module who has to do one thing and this one thing as good as possible demands efficient and sustainable solutions. Theoretically if you get that kind of code just right, you don’t have to touch it again for a long time.

On the other hand you have code where the codes environment is so volatile or ephemeral, that developing the appropriate code isn’t possible, because you are aiming at a moving target. This often demands faster solutions, shims, code that was never really meant to be maintained etc. Sadly many companies have a culture where these shims become like glorified tradition and a few years down the line you have a pile of shims that nobdy sane is willing to touch.

However there are situations where fast solutions make sense, e.g. because it is a one time thing or it doesn’t really matter that much etc.

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

#86

Post by crescentfresh »

adreamingsoul wrote: post #75
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…

Recently, I had someone join my team who was instantly popular and everyone enjoyed this person's personality. I trusted this person more then I should have and during a period when I was unable to give enough attention to their code reviews, they introduced several critical bugs and defects into the production environment. I never figured out if it was ignorance or laziness. But, either way I learned a valuable less…

> not everyone has the same level of ownership or commitment that I would expect

This is a good way of putting it. A dev might be junior and won't have the knowledge or skill to build stuff with minimal defects, but they can still have the sense of ownership and commitment to a quality product that a senior/trusted dev on the team has.

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

#87

Post by WalterBright »

andbberger wrote: post #67
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.

[citation needed] idk man, my code is pretty damn clean

I think my code is cool, too, until I look at it again 5 years in the future.

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

#88

Post by Gibbon1 »

mehrdadn wrote: post #4
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.

Isn't digital logic testing a thing for hardware?

Complex hardware often contains bugs many of which map to software bugs. Hardware though tends to be highly constrained in how it's operated.

Man: Doc it hurts when I bend my knee this way.

Doc: Well don't do that.

EE: The hardware state machine runs into the weeds when given these inputs.

Tech Rep: Yeah don't do that.

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

#89

Post by amelius »

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…

> As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts.

Do you use formal methods to prove the correctness of your code?

Because that is what Boeing engineers do (I hope).

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

#90

Post by AWildC182 »

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…

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 coded as something like (vastly oversimplified)

if(AoA >= MAX_AOA) trimPosition = g(f(AoA, IAS), trimPosition, dt);//AoA/IAS dependent ramp function

else trimPosition = g(trimInput, trimPosition, dt);//ramp function

not

if(AoA >= MAX_AOA) trimPosition += 1;

Because the latter is very likely to result in a runaway even if you have bounds checking somewhere else. Worst case you don't have bounds checking and the position value/register value loops over and the tail just starts spazzing out, flapping up and down as fast as the motor will drive it.

Post reply on HN