My understand is that the 737 Max was fine if they treated it as a new airplane. The problem was the put gizmos on it to make it behave like a regular 737 so pilots didn't need to get retrained on it. Those gizmos are what crashed it when you didn't know how they behaved when they failed.
The problem is that the whole point of the 737 Max was that airlines didn't have to treat it as a new airplane. If they did, it would have lost a lot of the value proposition and there would have been more support for an entirely new replacement instead. It would be a fascinating case study in perverse incentives and unintended consequences if it wasn't for the loss of life that resulted.
According to my research (watching youtube videos), putting those big turbofan engines (which had to be pushed forward and up to fit) gave the plane different flying characteristics which, under the rules of whatever, required new pilots to be retrained to some degree (at least flight simulator training), which made it a real pain for some airlines to ship their pilots off to wherever those simulators are.
> "testing" is not fundamental. there is no real skill to be learned there, it's just one of those things that will find a way to steal your time anyway so there is no point in focusing actively on it.
it is not edgy whatsoever. it reflects the actual reality on the ground.
nobody goes to school to learn how to use git or how to write unit tests. it's not something that needs to be actively "learned", you'll just absorb it eventually because you can't escape it.
The more interesting and important things you will never "just absorb", you actually have to make a conscious effort to engage with them.
one of the biggest problems that has plagued software is failed projects. There have been a lot of them, and its probably costs hundreds of billions of dollars.
I can guarantee not one of those projects failed because somebody had to take the time to look up the best data structure. But I'll bet a lot of them failed because they didn't follow smart testing practices and collapsed under their own weight of complexity, untestability and inflexibility.
I've seen projects fail for a multitude of reasons, by far the most common are boring political ones, like the leadership not understanding what it is that they want to build.
Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is.
I assure you that if you have enough competence to actually go through with designing and building a thing, you certainly have more than enough competence to test it. It is not a fundamental discipline that needs to be studied, much less at the expense of fundamental knowledge.
Edit:
to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain.
> Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is.
Citation needed.
> Edit: to reframe it a bit differently: you can always add more tests. you can't fix the problems you don't even know you have due to lack of thorough understanding of the problem domain.
The problem domain is never the data structure or algorithm.
Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs? All these systems had extensive test suites and yet these problems happened anyway.
Bugs happen in extensively tested systems literally all the time, but by your own logic, any bug is "due to lack of testing". That's an unproductive line of reasoning because it is not possible or practical to test for every possible eventuality. This is why fields like formal verification exist.
>> Hiring people who think bloom filters are "exotic" to work on a distributed system could certainly doom that project to failure regardless of how diligently tested it is.
> Citation needed.
ever tried to build a distributed cache??
> The problem domain is never the data structure or algorithm.
The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving.
> Do you really think you can prove your point by showing me some sloplist of mildly high profile bugs?
Whatever I link to you are just going to say its AI, or inconclusive. There's a section on testing in the Mythical Man-month, but I can't link it here. But I don't see anything on getting the "fundamental theory" wrong.
> All these systems had extensive test suites and yet these problems happened anyway.
They were obviously missing some important tests.
> ever tried to build a distributed cache??
Why would I if I could avoid it? And building that, rather than finding it somewhere looks like nudge towards a project failure.
> The problem domain is literally always that. The way your data is organized and the way you work with it is directly affected by the exact problem you are solving.
That's just basic programming in the type system of your chosen language, not "fundamental theory" as you call it.
> Whatever I link to you are just going to say its AI, or inconclusive.
There is no point in linking anything further because your line of reasoning is flawed to begin with, due to two reasons.
Reason one, your argument amounts to: software has bugs, and every bug is there because there was no test that would prevent that specific kind of bug (and it would if they were doing testing "correctly"). This is a completely vacuous argument because all software has bugs and therefore no one is doing testing "correctly" to your satisfaction anyway, which makes the whole discussion moot.
Reason two, you seem to be assuming that I am somehow advocating for not doing software quality assurance or not writing any tests. I am not. I am arguing that it is not worth investing extra time into learning that discipline, because a) not fundamental; b) you will be forced to learn it anyway. Therefore, spend your precious extra time on more interesting and useful things.
> But I don't see anything on getting the "fundamental theory" wrong.
Typically projects that get the basics wrong don't live long enough to find themselves in an AI training corpus used to generate listicles.
> Why would I if I could avoid it?
a simple "no" would have sufficed to establish that your opinion on usefulness of bloom filters in distributed systems probably shouldn't be weighed very high.
> That's just basic programming in the type system of your chosen language, not "fundamental theory" as you call it.
The fundamental theory bit helps to choose the appropriate data organization for your use case and either implement it yourself or modify a pre-existing implementation, or convince yourself that a pre-existing implementation is sufficient.
That just seems like bad luck for the experiment. I've never seen anything like that driving on the highway. Was the claim that it could go coast to coast no matter what was thrown at it?
And don't replace them with fake buttons that are also distracting. Buttons and knobs need to be designed so you can quickly glance to target them, but from then on, you can feel or hear how you are interacting with them.
It's not an opinion piece but a data-based summary. The sources are listed in the "Endnotes" section (listing 56 notes!) of the paper which you are free to study.
