The art of doubt
I run into the same story time and time again.
Someone stumbles upon a bug that they cannot explain. All plausible reasons are eliminated, but it still does not work. They call me for help.
When all plausible reasons are eliminated, what’s the next logical step? Start looking into less plausible reasons.
The amazing thing is, most people categorically refuse to “waste time” by verifying their “obvious” assumptions, even when faced with a problem they can’t explain. People know that custom port works exactly like standard port, that function Foo() never throws exceptions, that messages always arrive in a particular order, that the water in the Southern hemisphere whirls in the opposite direction, et cetera, et cetera. Furthermore, they put up significant resistance when advised to take actions that would verify that these assumptions are actually true.
“I see you are using the beta version of Bazooka service here. Let’s try production”
“But the Beta is exactly like production! I know it works just fine. It would be a waste of time!”
“Well, we don’t know what’s going on, maybe it is not exactly the same, let’s try it”
“Why should we try it? The problem must be something else!”
And of course, we switch to production Bazooka and it works. Bazooka Beta has a bug. If they were able to systematically test the “obvious” assumptions, they would not have needed me to find that out. But they can’t.
I guess this is more or less how religion works: experimentally verifying the dogmas is not only unnecessary, but highly undesirable. I can find the bug not because I am smarter, but because I am willing to systematically question “the obvious”, even if it sounds crazy.
Originally posted on www.ikriv.com/blog/.