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

#111

Post by AnimalMuppet » Thu, Apr 18, 2019, 10:29 PM UTC

crimsonalucard wrote: post #6

jsiepkes wrote: post #3

Earlier quoted context omitted.

Well we can prove some things behave under certain conditions in a certain way. We can't prove the absence of bugs.

No, we can literally prove it correct based off of a specification. https://en.wikipedia.org/wiki/Correctness_(computer_science) In science nothing can be proven but in the world of logics and math, things can be proven. Bugs can arise where programs intersect in the real world.

> Bugs can arise where programs intersect in the real world.

Well, the context is flight control software for airplanes. If that code is bug-free but doesn't intersect the real world, that's rather useless. And if it intersects the real world but therefore is not bug-free, that's not a great argument for proofs of formal correctness.

But all of that is kind of beside the point. The MCAS specification was the wrong thing. Proving the implementation correct is useless. (You asked what is a bug in a spec? MCAS shows you the answer. Only taking input from one sensor is the wrong thing. Repeatedly applying nose-down is the wrong thing. It seems like I'm missing one or two more.)

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

#112

Post by d-sc » Thu, Apr 18, 2019, 10:29 PM UTC

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…

Architecting solutions is hard. In this case, you need knowledge of motors, flight controls, sensor fusion, etc.

It’s easy to find edge cases when they present themself (tragically here). But most electrical-mechanical-software assemblies have similar issues.

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

#113

Post by anbop » Thu, Apr 18, 2019, 10:29 PM UTC

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…

Well, great code is inefficient if the impact of bad code is minimal. If you are shipping an animated emoji you should be sloppier with your code than if you are building flight control software. Overengineering software is like over-specing building materials by 10x and spending way more money on a building than it needs.

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

#114

Post by baddox » Thu, Apr 18, 2019, 10:29 PM UTC

Retric wrote: post #101

baddox wrote: post #94

Earlier quoted context omitted.

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.

It’s less about the domain than the impact of the code. Bad code can kill your company or go unnoticed, depending on where it is and what it’s doing.

Of course, but the solution for the vast majority of companies and projects isn't "never release code that isn't perfect."

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

#115

Post by ncmncm » Thu, Apr 18, 2019, 10:29 PM UTC

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…

I have frequently seen standards, guidelines, and "process" prevent improvements to code. Since change is considered risky, it takes more time and effort to document improvement than the individual change is worth.

But software improves, when it does, by a series of small changes, each by itself hardly worth doing, but in sum producing a wholly better product.

It is the process that turned lizards into birds.

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

#116

Post by blunte » Thu, Apr 18, 2019, 10:30 PM UTC

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…

I think you vastly underestimate the scale of an aircraft in whole. Your code is one thing, but the many systems it interacts with, the systems they interact with, and the possible outcomes, is almost unfathomable to a human.

And even in simple cases where the number of possible situations is calculable, you probably haven't covered all possibilities.

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

#117

Post by AWildC182 » Thu, Apr 18, 2019, 10:31 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.

It's more nuanced than that. My ramp functions technically have a += 1 somewhere in them. You just don't want to += a motor value directly or otherwise add to state out of a feedback loop. You can verify the PID function in simulation/unit test. It's much harder to unit test the motor/driver/controller on a stand.

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

#118

Post by rubicon33 » Thu, Apr 18, 2019, 10:31 PM UTC

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.

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.

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

#119

Post by blunte » Thu, Apr 18, 2019, 10:32 PM UTC

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.

Funny you should present it this way. My view is the opposite. As a self-managed, often solo developer, I find that team developers seem sloppy and very willing to choose not to consider the full scope of possibilities because they figure it's not their problem. Many of them work "to spec" and (rightfully?) choose not to consider the bigger picture.

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

#120

Post by theclaw » Thu, Apr 18, 2019, 10:35 PM UTC

sisu2019 wrote: post #98

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…

It was profits. Airbus did effectively same thing with the A320 Neo in 2010, and it became the fastest selling commercial aircraft in history [0]. Boeing clearly was unhappy with that and needed to do something to compete.

[0] https://en.wikipedia.org/wiki/Airbus_A320neo_family#Orders_a...