> [7 Software Failures Due To Lack Of Testing That Rocked The World](https://www.appsierra.com/blog/software-failures-due-to-lack...)

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.

▲

KevinMS 2 days ago | parent [-]

> 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.

	▲	nice_byte 2 days ago \| parent [-]
		> 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.