For the sake of a nice segue, I'm going to commit something that looks a bit like a dictionary flame. Since I hold dictionary flamers on a par with spammers (somewhere below pond scum.. a mental image I find pleasing), personal ethics demand that I first post a disclaimer, and give props where due.

So: bravo.. that was a nice, scholarly overview of Occam's Razor. It's rare to see someone actually go back to the source and discuss the idea thoroughly. The list of links alone earned you my ++.

Now I'll grab my hyper-pedantic asshole hat long enough to note that 'simplicity' and 'minimalism' aren't always the same.

William was talking about minimalism.. not using two pieces where one will do. The word 'simplicity' arrived later, which is nicely illustrated in the series of equivalent quotes you listed. All three of the earlier sources boil down to counting entities, as does Moody's from the present day. Only when we get to Einstein and Dirac does the more general concept of 'simplicty' come into play.

Sure, there's a version of simplicity that equals minimalism, but there's also a concept of 'piecewise simplicity' that almost inevitably leads to multiplication of entities. To quote H.L. Mencken:

For every complex problem, there is a solution that is simple, neat, and wrong.

That's something we, as programmers, need to care about.

I can't count the number of times I've seen code that starts from a few simple, easily-stated assumptions, then evolves into a Rube Goldberg machine due to inconsistencies among the assumptions. I've also spent a fair amount of time trying to pry coders loose from those simple-but-inconsistent assumptions so they can go back and write something that actually works. Some have defended themselves with the KISS principle, because digging out inconsistencies can be hard. More than once have I had to explain, "simple is not always easy," and, "simple means everywhere.. not just right here."

In the language of systems analysis, it's called 'globally suboptimal local optimization'.. fixing a problem in one place by creating an even worse problem somewhere else. If you really want to see that principle in action, divide a project among half a dozen coders, and reward them based on whose code profiles as fastest. It's a rare to find team that doesn't have at least one person willing to shove work off into somebody else's module.

So.. simplicity is a great goal, but remember to watch the global perspective. There are few better ways to write absolute crap than to get perky about making things 'simple' at the local level.