The simplest explanation is usually the correct one.
Actually, this is a bit of an oversimplification (but then, we’re fond of those, as I’ve written about before). Perhaps a more correct formulation might be:
Simpler explanations are, other things being equal, generally better than more complex ones.
At least that’s how Wikipedia chooses to present it, although it notes that the actual words that Mr. Occam (supposedly) said were:
Entities must not be multiplied beyond necessity.
(Only he said it in Latin, ’cause that made him sound smarter.) What you might notice about these successive phrasings is that it gets less and less emphatic. First it’s “usually,” then it devolves into “other things being equal,” and finally ends up at “beyond necessity.” Any way you slice it though, the point I’m making should be obvious: there’s a huge difference between the simplest explanation always being true, and it maybe possibly being true, unless necessity dictates otherwise.
Happily, as a Baladocian, I’m perfectly happy to believe both at once: the simplest explanation should be true, but it needn’t be. I’m pretty easy-going on several sayings like that. Here’s another one:
If it seems too good to be true, it probably is.
I absolutely agree with that ... especially the “probably” part.
The other day I was talking to a good friend (and co-worker) of mine, and he pointed out that he’s always highly suspicious of techniques (or processes, or solutions) that sound like a religion. If you think about it, that’s just the “too good to be true” thing all over again. In the computer world (you’ll recall that I’m a technogeek by profession), we run into this all the time, and I’m sure you’ve experienced it too, even if you’re not technical yourself. Got a friend who owns a Mac? Then I’m sure I don’t need to explain the Cult of Apple to you. And technology is full of those: there’s the Cult of Microsoft to battle the Cult of Apple, likewise the competing religions of vi and emacs, the people who so slavishly follow Excel that they use it for everything, from grocery lists to corporate databases, and on and on and on.
When I was a young (and foolish) programmer, I fell into such a cult myself: the Cult of OOP. OOP, or object-oriented programming, is a way to write software that is usually contrasted with procedural programming, although these days it’s more fashionable to compare it to functional programming. If none of that means anything to you, don’t sweat it—it isn’t crucial to my point. The point is, when I first had OOP explained to me, it didn’t sound that cool ... it sounded sort of simple and obvious, actually. Then I read a book on it—not even a very good book, as it happened, but enough to make me understand what OOP really meant. And, let me tell you: the skies opened up, and angels came down and blew their golden trumpets, and golden rays of sunlight lanced down, and all the darkness I had ever known was lifted, and I did see the light. Glory, glory, hallelujah. I didn’t know it, but I’d been converted.
Back in those days, OOP was just getting started: I really got in on the ground floor of that cargo cult. There weren’t loads of people wandering around proclaiming that OOP was the One True Way of programming ... not then. That would come later. If they had been around then, I, like my friend, would have most likely turned up my nose. But, as it turned out, now I’m one of the evangelists.
And here’s the thing: so is my friend. Because, you know what? OOP really is better. Not the “One True Way,” of course, because nothing can ever be that, but, given a system of sufficient complexity, that needs to be built at an average level of abstraction, OOP is almost always the best way to go. Call me a religious nutjob if you must, but it really is true. OOP lives up to the hype.
And yet there are still people out there who dig in their heels and put their fingers in their ears and go “LA! LA! LA!” and refuse to listen to the advantages of OOP, because those of us who know how to use it are just so goddamned enthusiastic about it. It’s very frustrating to someone like myself. Or my friend—I’ve seen him fighting with people who stubbornly refuse to listen to him when he’s extolling the virtues of OOP, and I know that expression on his face. It’s irritation, plain and simple.
So imagine how I feel when here I am explaining to him about something that I know really is a whole new awesome way of doing things—agile, perhaps, or TDD—and he’s telling me he’s suspcious, because he smells dogma. Well, sure: I’m suspicious of crazy zealots too. God knows, when my other friend (and co-worker) tries to tell me how awesome his iPhone is, I mentally close the door in his face, just as I would for any Jehovah’s Witness (or Mormon) that shows up and rings my bell. But, dammit: this particular stuff I’m talking about is different!
Of course, now I just sound whiny.
The title of this blog post is a reference to a saying attributed to 9th century master Lin Chi:
If you meet the Buddha on the road, kill him.
What this actually means, of course, is up each individual to determine, but a typical interpretation explains that the “Buddha on the road” is our conception of what Buddhism actually means, a symbol of the instruction of teachers and masters. And we must “kill” that external image, because enlightenment can only come from within. As the Buddha also (allegedly) said, as he was dying: Be lamps unto yourselves. Which (purportedly) means, don’t listen to what others tell you to do, work it out for yourselves. Of course, there’s a paradox here too: if we don’t listen to the authority of others because the Buddha told us to ... I talked about this in reference to quotes, but perhaps the best way to illustrate the words of the Buddha is with the words of another great philosopher: Steve Martin.
Now let’s repeat the non-conformists’ oath:
I promise to be different!
I promise to be unique!
I promise not to repeat things other people say!
Good!
The hype of whatever the latest technical methodology is presents us with a similar paradox. Popularity is no measure of quality—in fact, it’s more often the opposite. But, then again, if a new thing really is as awesome as these things generally claim to be, how do you expect people to react? Won’t they want to go around telling everyone, trying to share the good news with as many people as possible? Exactly like ... a cult. Which makes us suspicious.
I mentioned two things that many technical people find cultish: agile and TDD. There have been many screeds against both: Steve Yegge (who I mentioned last week) has a really famous one knocking agile, and here’s one plucked at random from a Google search which talks about TDD. Note how both use the word “cult” freely—gleefully, even. Both of these articles are very very wrong ... but, then again, they’re both right. They’re right about how people slavishly follow things they don’t fully understand and how stupid that is, even as they slavishly rant on, Dennis Miller style, about things that they don’t fully understand. I’m into paradoxes and all, but this is enough to make a guy’s head spin ...
In case you do happen to be a technical person, I’ll point you at one last article. This is a blog post by J.D. Hildebrand (an old friend of mine, as it happens), where he talks about how agile started out fighting the system, and now has become the system to be fought against. It happened, if I may paraphrase J.D. (who is indeed paraphrasing others, to some extent), because people joined the cult. They didn’t question what they were adopting, they just heard it was the latest cool thing and they picked it up and followed all the instructions to the letter.
This is wrong. One must always question. One must always be skeptical. But does that mean that one must turn up one’s nose at things just because they are touted by the masses? If we sneer at all those mindless drones, just to be hip, without truly knowing the facts, how are we any better than they are? A suspicious mind is not the same as a closed one.