Earlier quoted context omitted.
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 certific…
How the Boeing 737 Max disaster looks to a software Developer
291–300 of 306 posts
Re: How the Boeing 737 Max disaster looks to a software Developer
#292Earlier quoted context omitted.
This is bonkers. Nobody anywhere in the world should expect that one buys an airplane which is unsafe by design. Also, the idea that there are two versions of a plane, one that kills people and one that doesn't, and if you buy the wrong one that's completely your fault is just insane.
Frankly, you have no idea what you're talking about. This is how the airline industry works. Airlines WANT cheap planes and they ARE WILLING to and DO skimp on some safety features to save money. Airlines WANT safety features, at least some of them, to be optional so that they aren't forced to spend money on them if they don't want them. For example, backup fire extinguishers in the cockpit? Optional. Extra oxygen ma…
There is no excuse for a company such as Boeing, working under the regulation of the FAA, to produce any version of any model of plane which is fundamentally unsafe to fly. Period. None.
We're done here.
Re: How the Boeing 737 Max disaster looks to a software Developer
#293Earlier quoted context omitted.
Frankly, you have no idea what you're talking about. This is how the airline industry works. Airlines WANT cheap planes and they ARE WILLING to and DO skimp on some safety features to save money. Airlines WANT safety features, at least some of them, to be optional so that they aren't forced to spend money on them if they don't want them. For example, backup fire extinguishers in the cockpit? Optional. Extra oxygen ma…
There's plenty I could say in answer to this but most of it is unnecessary. There is no excuse for a company such as Boeing, working under the regulation of the FAA, to produce any version of any model of plane which is fundamentally unsafe to fly. Period. None. We're done here.
Re: How the Boeing 737 Max disaster looks to a software Developer
#294"Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not." I wonder if, once basic programming become…
I reject the notion that one must become a monk to be a programmer. There’s a happy medium between cave troll and brogrammer to be found.
As developers we should have more hobbies. We should find the technical aspects of those hobbies, and we should be able to walk into a company serving that community and serve as a backup SME from day one. If Software Is Going to Eat the World, that is how it will be. Not from a bunch of smart stupid people “disrupting” industries they know nothing about.
There’s long tail of subject matters without a lot of money that could still use software. Getting software to them is going to take cheaper labor, like 2-person teams or possibly volunteer work.
Re: How the Boeing 737 Max disaster looks to a software Developer
#295Earlier quoted context omitted.
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 certific…
Its not very easy to redesign the 737. Bigger Engines need more clearance. More clearance requires longer landing gear. Longer landing gear requires a wider plane to fold up into. A wider plane is less fuel efficient and needs bigger engines and suddenly you are a 757,767,787, or 777
Too bad. I know I am now permanently reluctant to fly 737s
Re: How the Boeing 737 Max disaster looks to a software Developer
#296Earlier quoted context omitted.
Its not very easy to redesign the 737. Bigger Engines need more clearance. More clearance requires longer landing gear. Longer landing gear requires a wider plane to fold up into. A wider plane is less fuel efficient and needs bigger engines and suddenly you are a 757,767,787, or 777
> Its not very easy to redesign the 737. Too bad. I know I am now permanently reluctant to fly 737s
MCAS is not a feature to correct an unstable aircraft, it's to correct a confused pilot. MCAS is triggered if the following circumstances are right: 1) The airspeed is near stalling speed (takeoffs and landings) 2) The AOA (as reported by both sensors now) is greater than the aircraft can climb.
The problem was that 1) the AOA data was faulty, 2) it did not check if there was a disagreement with the backup system 3) The aircraft failed to reset each time it took corrective measures such that each the correction was compounded. 4) the corrective action was 3 times more than approved.
All of these things have been fixed but it also shows how many things have to go wrong for something to be catastrophic. But the max has been built on a solid foundation and that's much better than having to start from scratch.
Re: How the Boeing 737 Max disaster looks to a software Developer
#297Earlier quoted context omitted.
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
#298Earlier quoted context omitted.
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?
In a type checked language. Your software is guaranteed to have no type errors. How hard was that?
A necessary part of why types are so useful is that understanding the types is easier than understanding the code itself.
If the types become so complex that they start to get harder to understand than reading your code (e.g. C++ template errors can sometimes get this bad), then they are no longer helpful.
Re: How the Boeing 737 Max disaster looks to a software Developer
#299Earlier 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.
Functional safety is the engineering discipline related to designing machinery instrumented safegaurding systems to protect humans from harm, to a deterministic safety performance level.
eg just the right amount of safety so that all the safety money is spent in the right places and right amounts so as to reduce risk across the board to the required level, not over-investing in one area and neglecting another (or so the dream goes, in practice it is a moving target based on a lot of guesses, you hope the swings and roundabouts balance out more or less).
Aeronautics design is one of the closely aligned fields within the group of this overall discipline. Closest thing I have worked upon in terms of risk/consequences is mine winders - safety failure can kill 10-100 people in one go, they ride multiple times every day.
Right now, this very minute before needing a break at 1am to browse hacker news, I was trying to wade thru a mess of a fault tree analysis my current project owners "specialised" consultant has produced for the systems I currently need to instrument for safety.
Most people in general, but especially Americans who live primarily with prescriptive standards, struggle to come to grips with the nature of performance based safety standards. There is no "do it like this and you have met code and have no problems" - you have to analyse and build everything up from scratch.
It is all about layers, layers of risk reduction that eventually (whether by perception or reality) get the risk down to an acceptable level. So there are cludgey little things that get stuck on as hacks to address this issue or that, not uncommonly often pet issues of one of the review panel. Repeat this several hundred or thousand times and any hope of some kind of uniformly elegent and simplified solution is pretty slim.
The general reliance is on redundancy and independence, eg layers of protection, "defense in depth", or as more commonly known "the swiss cheese model" - you get a bunch of slices of swiss cheese and when the holes line up to allow a path through, that is when an accident can occur. More layers, less chances (also smaller holes, but that is another story again).
And, as almost always, the machines are actually the easy part most of the time. It is the humans that design, build, test, maintain, certify the machines that are the weak point, over and over again. Plus the creative ways humans can get around systems in place to protect them, get their job done when the system is telling they should stop, or doing a maintenance task a new "better way" despite the manual that might have cost over $100k plus of engineering time to write and approve is telling them to do it a specific way etc etc etc
90% of the time overly conservative thinking during risk analysis occurs (we might get hit by a meteorite, happened to my cousin once), which can layer complexity and associated uncertainty and poor availability onto a solution.
10% of the time there is the wishful thinking of "it will never happen because I have never seen it or heard of it" that allows the unexpected and unusual (black swans often, if you will) to sneak through, at least for the first time. Endless discussions occur about "credible scenarios", sometimes the "discussion"is won by the dominant personality in the room, who might also be doing some of the pay reviews next month.
It is incredibly difficult to be the person that has to herd the flock of cats that represent all the stakeholders in a hazard revue and risk assessment. These workshops sometimes run for months, maybe in extreme cases for years on and off, considering every system, subsystem, part, action, event, procedure etc etc and all the possibilities and how they can go wrong and what might mitigate failures and events - and on and on.
I could write about this all night, but I guarantee you that any magical opinion or assumption you might have about graceful and elegant solutions to difficult and dangerous problems being the norm are unrealistic - there is a always a consensus or committee to satisfy, often top heavy with people that might have to own or operate the machine in question, but never designed anything in their lives. You fight for the things you know matter and concede some of the crap, hoping subsequent reviews will see it as pointless or not credible.
All of this is the reason that grandfathering is so attractive. To apply the current internationally recognized performance based safety standards from scratch to design something as complex as a plane that can kill hundreds of people in one go is an incredibly difficult task. And from a business perspective fraught with immense dangers of totally unpredictable outcomes impacting budget and schedule and even viability.
This is a highly specialised field with what are often counter-intuitive outcomes (otherwise you would just let John out the back room design the whole plane from scratch, because "he knows what he is doing").
While I am aghast at some of the information about some of the information about design decisions taken that is emerging, none of it surprises me in the least. I can see directly how a number of them may have effectively resulted from path of least resistance when a product had to be produced.
I like flying older planes in general, as long as the airline does reasonable maintenance. The unexpected has often been detected and corrected, the chances of latent faults turning up decrease with hours in service. Plus I always remind fearful daughter that the taxi ride to the airport is more dangerous, by the numbers.
Re: How the Boeing 737 Max disaster looks to a software Developer
#300This 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…
I don't know, I think the 3 points in the article make it glaringly obvious that the root cause is NOT engineering. The decisions made clearly ignored engineering and historical precedent at every turn. It's sad because Boeing has had some wonderful engineers, and Boeing aircraft have traditionally allowed the pilots to have the final say.