Live data from Hacker News

How the Boeing 737 Max disaster looks to a software Developer

spectrum.ieee.org

261–270 of 306 posts

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

#261
Let me tell one thing: I absolutely hate sloppy engineering. And by sloppy I also mean rushing. There is a class of engineers and engineering managers who think that they are rockstars because they can churn out code quickly. I am absolutely disgusted and sick of this attitude.

And why do I bring it up here? Because I suspect this kind of attitude was partly blamed for this fatal and tragic accident. Of course this is pure speculation. But my 12 years experience in the software industry makes me believe that's what happened.

Also a relevant talk by Uncle Bob: https://youtu.be/ecIWPzGEbFc

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

#262
post #156
post #141

Earlier quoted context omitted.

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…

Ultimately it was not a technical failure: the failure was in allowing the plane to be sold with such a thoroughly bad design. Thus, a management and regulatory failure. Regulatory, because FAA signed off on it, obviously without applying any of the process that would have prevented it. Management, because the cost of this debacle will be many, many times what they saved by trying to skate by with a faulty design.

You watched the VOX video and are reposting the summery here?

They are going to fix the software with no changes to the design.

They don't need to change the design, that would be expensive overkill. Software updates are as close as we can get to Free. There is not a single company or human with infinite money to spend on anything, we can't always have the fantasy.

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

#264

Let me tell one thing: I absolutely hate sloppy engineering. And by sloppy I also mean rushing. There is a class of engineers and engineering managers who think that they are rockstars because they can churn out code quickly. I am absolutely disgusted and sick of this attitude. And why do I bring it up here? Because I suspect this kind of attitude was partly blamed for this fatal and tragic accident. Of course this i…

>I absolutely hate sloppy engineering.

>Of course this is pure speculation

Cool ideas, people have already figured out this was designed into the system. Sure more testing can catch things, but how much money are you allowed to spend on every single feature?

There isn't a 'right' answer to these questions, engineers are literally doing cutting edge, never before jobs.

Everyone wants more time, more money, and better suppliers.

You need a call to action, not just a youtube video talking about groups not being responsible.

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

#265
“ 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. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.”

This is why I feel the software industry has too many problems with security, performance, etc.

I’d like to think that engineers care how good and efficient their code is. But too often, it’s up to managers or customers how quickly software needs to be completed.

This introduces bugs, incomplete features, and (in the case of Very Important Thigs to keep you Alive) potentially cause dangerous breaks.

It sounds like Big Corp was trying to push that laziness and lack of foresight into other engineering disciplines. If so, how many of our cars, planes, and other items that potentially directly affect our lives are affected by mechanical design flaws and software errors?

Hopefully the industry gets its shit together as a whole. As it stands, if I ever work on anything that affects a life, I’m damn well blowing a whistle if I feel like something is off.

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

#266
post #156

Earlier quoted context omitted.

Ultimately it was not a technical failure: the failure was in allowing the plane to be sold with such a thoroughly bad design. Thus, a management and regulatory failure. Regulatory, because FAA signed off on it, obviously without applying any of the process that would have prevented it. Management, because the cost of this debacle will be many, many times what they saved by trying to skate by with a faulty design.

You watched the VOX video and are reposting the summery here? They are going to fix the software with no changes to the design. They don't need to change the design, that would be expensive overkill. Software updates are as close as we can get to Free. There is not a single company or human with infinite money to spend on anything, we can't always have the fantasy.

The MAX can be fixed by addressing the flaws in MCAS, and it will be in the end. The production will resume, the MAX will be a slightly less commercial success than it should have been, Boeing will be fined a few Billions for its failings, the FAA will have to take an hard look at itself, and everything will be ok.

I just hope the correct conclusions will be learnt from this crash:

* have a truly independent certification process

* don't fix your physical design issues with software

* don't write and maintain software running on an airplane like the software from the start-up world: significant design flaws are not tolerable for software running in an airplane, even if they can be fixed easily.

* don't hide new systems, if there is a new system, then pilot should be trained

by the way, it's not the first time a new system caught pilot by surprised because they didn't knew about it. SAS Flight 751 is another example, ice ingestion damaged the engines, the pilots reduced the thrust to reduce stress, but an automatic system (ATR, Automatic Thrust Restoration), unknown to the pilots, put the thrust back to full power, disintegrating the engines, the plane fortunately crash landed without fatalities thanks to the pilots skills and a bit of luck.

* Boeing should really think about replacing the 737, the old design is putting too much constraints, preventing a clean design.

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

#267

Earlier quoted context omitted.

That would be an overworked engineer IMO. Should the engineer that designs the air frame go weld it together? One issue, if the system resetting and no honoring the maximum authority to do so would not have been caught by a half-software engineer. That's definitely something the software team should have caught if there was any amount of reasonable QA involved. It's clear to me Boeing doesn't employ capable people on…

Not necessarily go weld it together, but they should be going and spending time with the welders. Ben Rich’s memoirs from the Skunkworks talks about this a fair bit. Around there, having the engineers close to the fabricators was one of their central tenets, and the engineers did occasionally roll up their sleeves in the shop. With the SR71, at one point when they were fighting with a nasty engine problem, Ben himsel…

I agree, they should work as closely together as possible. But it's still a team effort, not one person involved in large aspects of the process by themselves.

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

#269
post #260
post #186

Earlier quoted context omitted.

There are thousands of “hacks” like this in every modern airliner. That’s how complicated problems are solved, you come up with a basic idea, and you iterate on it thousands of times until you squash all the edges cases.

There really aren't. Please don't state opinion as fact. There aren't "thousands" of "hacks" to make an airframe fly reliably. That is preposterous.

Please don't state opinion as fact.

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

#270

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.” Whoo…

> I'm sure there's more

How about this one:

> "The solution was to extend the engine up and well in front of the wing. However, doing so also meant that the centerline of the engine’s thrust changed. Now, when the pilots applied power to the engine, the aircraft would have a significant propensity to “pitch up,” or raise its nose."

The centerline of the engine’s thrust moves up, doesn't it (the constraint is the floor, bigger engine requires you to go higher, wings are in the way, so you go higher and forward), so presumably it moves closer to the centre of gravity, giving you a shorter lever, thus full throttle should give you less aircraft nose up momentum.

In reality, the issue is (as far as I understand) that the nacelles generate lift that is further out in front of the centre of gravity, giving you a longer lever, and that's what produces a stronger pitch up (under high AoA) than before.

EDIT to add:

The article mentions that later:

> "And the lift they produce is well ahead of the wing’s center of lift, meaning the nacelles will cause the 737 Max at a high angle of attack to go to a higher angle of attack."

The relevant property is not that the lift of the nacelles is ahead of the centre of lift, but ahead of the centre of gravity.

Post reply on HN