I do think a lot of these are not Bug Blindness, but a bar for acceptable quality standards.

A low bar means people walk past without realising it, a medium bar may take notice but it doesn't bother them and tends to get throw out within min or seconds. A high bar gets insane irritation that some may even call OCD.

And unfortunately, these spectrum follows an S curve. If you have a high bar, you are likely in the single digit percentage monitory. And the same is across all things not just software.

▲

crabbone 20 hours ago | parent [-]

I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong.

So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations. And, if anyone should be given the power to act on it, the QA seems to be the most likely candidate.

▲

sakjur 18 hours ago | parent [-]

> So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too?

Good thoughts and framing, thank you for that. I think I'm in the former camp, because I think fixing bad expectations is a matter of thoughtful redesign that should follow a slightly different process to fixing bad implementations (what I would call a bug). Not every issue in a program is a bug, and that has nothing to do with the importance or urgency to fix the issue.

Assuming a rigid product organization, I think developers _should_ ask testers to escalate "works according to spec" even if the spec is unreasonable. Otherwise developers might be torn between QA, UX, and architects fighting about how something should or shouldn't work. At least for me, finding myself in such a position is a recipe for excessive meetings and losing focus on other equally important matters.

	▲	ksec 14 hours ago \| parent [-]
		I am in latter camp. Although I also agree with you on >escalate "works according to spec". But let me use Steve Job's phase, "you must start with the customer experience and work backwards to the technology". A bug to developers is work according to spec, but a bug to a user is that is it has mismatched expectations. And it really should be someone's job to make sure this is corrected. But as parent said, there hasn't been one in most if not all companies. And perhaps that is what makes old Apple such a success. They have a low pay $1 dollar salary beta tester to test out literally everything.