Occam's razor

I am reading a book on philosophy. I am no philosopher. I am not good enough, I don't think. But I found this book by accident in a bookstore. I read the back cover, and decided to buy it, initially attracted by the title of the book: "Zeno and the Tortoise". That reminded me of "Godel Esther Bach", a book that I read so many times, trying to finish, always failing, that I picked it up.

It is a very good book for me, as I am rather hopeless in terms of understanding the subtleties in reasoning and the precise wordings that are prevalent in philosophy texts. This book is direct and simple, and it tells very good stories about the life and time of the philosophers the author chose to highlight. One of the philosophers is Occam, or Ockham. He is of course famous for "Occam's razor".

If there are two theories that explain a certain thing, the simpler one is to be preferred, other things being equal. I paraphrase, probably not terribly accurately. But hey, that is all I can get from the book with my philosophy-deficient mind.

When I was reading the little essay about this little saying, I was thinking, can this possibly be applied to software architecture, software design, and software implementation? And are we doing that at all? Sadly, after a few minutes, I have to conclude, from my experience, from my readings, and from talking to other people, that it is not practiced by software professionals. And I think I know why.

I believe in the elitist notion that most people don't know what they are doing and don't really care that is the case. So, I will discount most situations where simplistic solutions are deployed. The solutions don't even adequately handle the problems they mean to solve. So, they are not candidates for the razor. Let's pay attention to only people who do know what is going on.

In our society, our employment marketplace, I don't think it is monetarily advantageous for software architects, software designers and programmers to choose the simplest but adequate solution for their programming problems. For the designers and programmers, how can they learn some fashionable techniques and libraries and frameworks that are not exactly needed by the problem at hand, if they don't use these techniques, libraries, frameworks for the problem at hand anyway? For the architects, if the solution is simple, their employers might think that they could have done it themselves. Simplicity is not appreciated in the software industry. Complexity awes people. So, it is in the advantage of all involved to choose something that is much more complicated as long as it fulfills these desires: complex enough to fool the mostly non-software savvy managers for the architects, using whatever is fashionable for the designers and programmers so that they can learn all these things that they might need to know to land their next jobs.

So, I think the result is that we could have EJB around for so long without overwhelming opposition---I simply refuse to think that we did not have many people doubting the wisdom of such a thing, right from the beginning. And everybody happily assumes that to be enterprise worthy, they must deploy a full-blown J2EE container, even though it might only be a simple website that goes to the database to get some data to show as HTML.

And of course, I have been asked the same question for so many times, I probably should think of a boilerplate answer: but can your system handle 1000 times as much traffic? Well, can my stomach handle 1000 times as much food as I need to eat? If that question is irrelevant, what makes the previous question more relevant if there will never be 1000 times as much traffic?