Gettiers in software engineering (2019)
Engineers are using the philosophical “Gettier problem” — cases where someone has a justified, true belief that still doesn’t count as real knowledge — to think about debugging and root-cause analysis in complex systems. Commenters trade war stories of coincidental failures, misleading signals, and code that “only works by accident,” arguing that better monitoring, testing, and mental models are needed to avoid being fooled by papier-mâché cows of software. Along the way, they connect this to broader questions in epistemology: what it means to “know” something, why justification is slippery, and how probabilistic or pragmatic notions of knowledge may be more useful in practice.
Access to the paper
- Original Gettier PDF link was overloaded; several alternates were shared.
- Commenters note the paper is extremely short, plainly written, and worth reading directly.
Gettier problem & justified true belief (JTB)
- Many discuss classic Gettier cases (cow/papier-mâché, stopped clock, misleading TV, Zoom background) and how they challenge “knowledge = justified true belief.”
- Some propose fixes (e.g., justification must itself be a justified true belief; justification must be causally connected to the truth; evidence must be true) but others note these lead to regress or further complications.
- Disagreement over whether Gettier’s argument is deep, overblown, or mostly semantic hairsplitting about “know.”
Knowledge, belief, and probability
- Repeated tension between “you can’t know falsehoods” vs. “people clearly ‘know’ false things in everyday language.”
- Several argue knowledge is better seen as degrees of belief or probabilities, not binary truth.
- Bayesianism and pragmatism are cited as more realistic: we manage uncertainty and update beliefs, not chase absolute certainty.
- Popperian falsifiability is raised: universal claims can’t be proven, only falsified; particular claims can be supported once a counterexample appears.
- Physics is framed as replacing JTB with “testability and predictive success” rather than justification.
Parallels to software engineering & debugging
- Many relate Gettier-style coincidences to debugging: “coincidental failures,” red herrings, and bugs that appear linked to the wrong change.
- Stories: multiple independent faults conspiring, legacy systems “haunted forests,” malware-laden forgotten clusters, code that worked only by accident, tests masking paired defects.
- Emphasis on:
- Strong monitoring, metrics, and observability instead of trusting mental models.
- Bisection, reverting to known-good states, and “introduce a known error” to verify you’re editing the right thing.
- Accepting that large systems can’t be fully understood; you need instrumentation, not just reasoning.
Meta: philosophy, models, and LLMs
- Some see Gettier and JTB debates as classic but somewhat quaint or narrow, especially compared to probabilistic or model-based views of knowledge.
- Others defend philosophy as foundational “front trench” work preceding formal science and logic.
- LLMs are likened to “papier-mâché cows” or “cargo culting as a service”: outputs that look right without grounded epistemic guarantees.