But it’s not a real defense for the Max because the problem with the Max is that Boeing has shifted a lot of the work from hardware to software.
This defense only punts the ball a few yards because the question now is why Boeing chose to shift a lot of the reliability from hardware, which this defense admits is better engineered, to software, which it admits is almost intrinsically worse.
If anything, this defense leads to the conclusion that the Max is an intrinsically unsafer plane, because it has shifted far more of the burden to software which is an intrinsically worse engineering discipline.
If it was just a matter of the software QA being rushed then the additional time gained by the grounding of the planes could solve the problem. But if it is software engineering itself which is the problem then no additional time will help unless it leads to shifting some of the burden of safely flying the plane from software to hardware, which doesn’t even appear to be an option Boeing has considered.
[1] https://www.theregister.co.uk/2018/01/26/cloudflare_crashes_...
Because most of it is software anyway. Unless the CPU is something ridiculously simple, like an 8-bit microcontroler, a lot of the instructions are executed by microcode stored in ROM on the CPU. What those patches do is load a replacement software in RAM at boot time.
It's taken me a while to come to the realization that all project management is is a backlog manufacturing and prioritization layer that operates on top of actual software engineers.
Most just want to implement things, and don't care what it is they are implementing as long as they are getting paid.
This is so not true.
Processes? Like T-CMM/TSM, FAA-iCMM, ISO 90003, TCSEC, TSP, etc., etc.? Languages? Like Ada, MISRA, Modula-2/IEC1131, Cyclone, etc., etc.? Tools? Like FRAMA-C, MALPAS, SPADE, SPARK, TLA+, etc., etc.?
The simple fact of the matter is that we've had all the processes, languages & tools to write high-reliability, secure code for decades. Go check out the CMU SEI for how long that one institution has been trying to get people to do the right thing.
The joke is that the software industry by and large wants to pretend we don't, and claim that there's some magical new tech that needs to get invented and when it arrives everyone will jump on it and suddenly software bugs will be a thing of the past. And every new tool, tech or whatever that shows up re-proves some unpleasant basic facts: writing secure, provable, reliable code is time consuming, usually difficult, which translates to relatively expensive. And the software industry doesn't want to hear that, or invest in it, and excuses it's miserable security record with "it's not us, the tech doesn't exist to do the job right".
As a sidenote, this is why I have a visceral distaste for the Rust people (the language seems fine). If they'd spent those (presumedly) thousands of man years building on and improving Ada instead of being all NIH averse we'd be much further down the road. They could have participated in the process and gotten their wish list included in the Ada-2012 standard and built on 35+ years of experience. But, hey, it's more fun to start from scratch every decade or so.
Now if you're talking about features that don't touch these things, go nuts. And there lies a second issue: the identification and distinction between what stuff is "go nuts" and what stuff is "do it right the first time". You can't approach every project with the latter or you'll waste so much time in the design phase when really you should just throw your new CSS theme out there and see how it goes. But you just can't approach the "account creation" feature the same way.
And yes, corporations aren't people, corporations don't have morality, I've heard all those excuses. Those corporations are comprised of people and those people should not be held to a lower standard.
The 737 Max is much worse at doing things that were done much better for decades before it.
It's another matter entirely to pass on the flawed device to a third party with no preparations and warning. Then people die.
Given that attitude, it's no wonder 99% of software out there is utterly bug-ridden.
Testing is not only not enough, it's also not required :) (as Dijkstra said, it can only show the presence of bugs, not their absence)
For example, the software for some automated subways in France has never been tested, only proven correct (source: https://www.youtube.com/watch?v=jc9QmqKIUj4&t=54m50s).
Similar formal methods are used for critical software pieces in Airbus aircrafts (source: the same speaker as for the linked video, but I don't remember which talk that was in).
But I guess (again) that having formal specs getting proven helps to avoid inconsistent specs. I recall a talk by Martyn Thomas where he said that with these methods it was harder to get programs to compile (for example, the compiler could complain if it detected an inconsistency, either between the spec and the program or within the spec itself).
Those processes are expensive. It'd imagine that they're a huge political problem to maintain, giving cost-cutting pressures and the temptations of COTS [1].
[1] https://www.faa.gov/aircraft/air_cert/design_approvals/air_s...
So it all makes me wonder about the official maturity of Boeing's 737 team, and also how much that rating relates to actual software quality and safety objectives (as apparently achieved in the space shuttle work)....
But they are also super expensive.
And no one has any money to spend on anything like testing or quality any more.
My original point was that flight critical software shouldn't be lumped in with the bugs-typical world of software. I still say that's correct.
But "bug" has a range of meanings. From what I read of the story of the original fatal error on the 300 MAX, the software was not buggy in the sense of "deviating from specification". It's just that -- as it turns out -- the specification was bad, and the MCAS should not have overridden pilot input when it did.
In a sense -- the one I consider most important -- that matches my model of flight-critical software. As software, they made absolutely sure that, in every case, it did what it was intended to; to the extent that it was in error, it was not in the sense of "we failed to make the software do what the spec says".
OTOH, I agree that "bug" is taken more broadly in software than the sense I was using here, that there usually isn't such a clean ("Waterfall") separation between "specifying what the software should do" and "ensuring that it does that" -- there's a collaborative process of ferreting out the implications of "what the system should do at what points".
In these latest events, it looks like the bug was in the narrower sense I meant above, of "it doesn't meet the spec", and that bug was found before deaths. From the article:
>The problem was that an indicator light, designed to warn of a malfunction by a system that helps raise and lower the plane’s nose, was turning on when it wasn’t supposed to, the company said.
Now, in fairness, that's a much later discovery than my optimistic model held, but still far earlier than "being used for flying the public around", as (the analog of) might happen with the software industry more generally.
What is worrying is that there could be many other potential sources of failure which simply didn’t trigger because the MCAS situation was so bad it led to 2 plane crashes before they even had a chance to bring down some planes.
In other words, if you have 2 bugs, one with a 1/100 chance of triggering and the other with a 1/1000 chance of triggering, by the time you hit 500 attempts, odds are the first bug triggered twice, while the second didn’t even once. So you solve the first bug, that still leaves you with a problem that has a 1/1000 chance of triggering, when the expectation is that bugs should only trigger at worst 1/10000 times.
Solving the MCAS issue is not by itself a reliable indicator that this is a safe plane to fly, especially since we know there are many fundamental procedural reasons to be worried about the quality of the plane.
The entire purpose of MCAS was to override pilot input as the typical instincts of a trained 737 pilot is to do the wrong thing. The failure was not handling edge cases (conflicting or missing sensor data) and no clear way to turn off the system when it was failing.
(I didn’t say anything about GP being wrong, I simply gave more details about the how and why)
Gotta fundamentally disagree with you right there. We absolutely can make high-quality software with our current tooling. The issue is that doing that is expensive and time consuming, and the Market optimizes on good enough to be sold and not dropped.
This expense and difficulty isn't an inherent fault of the tools, but rather the monstrous other side of the coin in proving what your system isn't.
There are many implementations that are composable to generate an end result, the trick is to expend the energy to ensure you've made the specific one that also doesn't run into undefined behavior, domain specific or otherwise.
You will never escape from the tyranny of having to clearly communicate to a perfectly obedient machine exactly what it is you want it to do; part of which is being able to identify when you don't have all your requirements right.
Airbus has designed their planes to counteract bugs by adding tremendous amounts of redundancies. The Max is Boeing’s effort at creating an Airbus like plane without the redundantsafety features.
Unless we see fines based on a percentage of revenue or the CEO/Board of Boeing being thrown in prison, then we won’t see change.
I agree with you. However, if you're not some high level manager who controls this, what's the next best thing you can do?
I think most problems are less technical and are more about people and processes. You can still argue you don't have enough influence there, and that's completely possible and realistic. But that should be where we direct attention.
Yes, some technical advances in better tools and languages that provide stricter proofs and so on are needed and will help. But ultimately it's still the people that need to learn, use, and enforce the processes.
My dishwasher stopped working today. Last week I had to replace a wheel bearing in my van ($900). I just got a refund for a pond aerator that stopped working after a few weeks. And the head came off my plastic toy.
Hardware fails all the time: does that mean I can generically say all manufacturing has shitty QC?
See MCAS programmers at $9/h.
> Increasingly, the iconic American planemaker and its
> subcontractors have relied on temporary workers making
> as little as $9 an hour to develop and test software,
> often from countries lacking a deep background in
> aerospace -- notably India.
Found it. Was Bloomberg. Here is the old thread.
Boeing has literally relocated their plant operations cross-country in the past in order to break the workers' unions.
Just think about how much pressure they can exert on a non-union profession like software development.
E.g. just to use a random example, Russian statistics show that the average pay of an architect is something like $800/month in many regions - in some more, in some less, but definitely well withing $9/hour; and for doctors in regions outside Moscow it's something roughly similar; Moscow seems to get something like 2200$/month in the average statistics so that's more than $9/hour if they're working sane hours.