similar to the concept of ockham's razor. many people with little familiarity or experience with actual philosophical work seem to believe the razor urges you:

similar to the concept of ockham's razor. many people with little familiarity or experience with actual philosophical work seem to believe the razor urges you: "the simplest explanation is more likely to be correct." however, the razor actually says: "do not multiply entities beyond necessity." the point here--and it's not just for programming or logic--is that you can make your explanation as big/small complex/simple as you want, but if it's more complex than it needs to be to adequately explain what you're talking about, ockham says: cut it down. if my theory has 1000 elements, your theory has 2, and we predict slightly different results to some experiment, ockham has nothing at all to say to us. ockham's razor is only useful regarding predictively equivalent theories. if ockham were saying "keep your predictions simple stupid," his razor would be trivially bad, and its implications trivially false. similar to code: if it doesn't work, its elegance is irrelevant. virtues like parsimony, elegance, or even scalability and the like are built on top of actually doing the job in the first place. edit: p.s. people are attacking the article for its strawmen, or for being too simplistic re: speed vs quality. i don't see how either of those get in the way of the author's fundamental point: don't overengineer, or mistake "objective quality" (???) with what's called for in a project. if i'm buying a $100 laptop, i'm upset that it doesn't have a haswell i7, but i'm not immediately wondering why the laptop's processor is so bad because it doesn't have an i7. ideas need to be kept straight.