The Solving Of Mysteries
Nov. 28th, 2011 10:11 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kerravonsenThere is a common mistake in so many mysteries, whether classic or SF-themed (Original Trek was particularly guilty of this): that the thing they're looking at (whether it be a mysterious curse, an unknown poison, a strange lifeform, or something else) is COMPLETELY UNLIKE anything else they've ever encountered. The writer doesn't realize that (a) such a thing is extremely unlikely and (b) such uniqueness actually makes the mystery EASIER to solve, because rather than looking for a needle in a haystack, they're looking for an echidna in a haystack. The real thing that makes a mystery harder to solve is when the phenomenon is not unique, but when it is very similar to other things, so similar that it could have multiple causes. When the phenomenon is unique and one can't find out anything about it, it shouldn't be a cause for despair. The lack of data is data in itself, because it eliminates a whole slew of possibilities that one now doesn't need to waste time investigating.
Why do I say this? I say this from my experience as a computer programmer, which means I have decades of practice in detection - of bugs in computer programs.
Here are a few rules of thumb that I've learned over the years:
* The most common explanation is the most likely. Investigate that first.
* Contrariwise, don't assume that the most common explanation is what happened; actually investigate it.
* Witnesses are unreliable; they will tell you what they think caused the incident, not what actually happened. Skill in questioning witnesses is required.
* When doing experiments, one must reproduce the original problem, preferably in a similar but cut-down form, whether that be experiments on mice or specially-written test programs, or whatever else. Otherwise one can't be sure that the proposed solution is an actual "cure".
Why do I say this? I say this from my experience as a computer programmer, which means I have decades of practice in detection - of bugs in computer programs.
Here are a few rules of thumb that I've learned over the years:
* The most common explanation is the most likely. Investigate that first.
* Contrariwise, don't assume that the most common explanation is what happened; actually investigate it.
* Witnesses are unreliable; they will tell you what they think caused the incident, not what actually happened. Skill in questioning witnesses is required.
* When doing experiments, one must reproduce the original problem, preferably in a similar but cut-down form, whether that be experiments on mice or specially-written test programs, or whatever else. Otherwise one can't be sure that the proposed solution is an actual "cure".
