I'm a fan of Jason Fried, the 37 Signals founder who sticks to his guns and stands up for simplicity in software design. I like how he's a dissenting voice and clearly has the courage of his convictions. I like how he promotes what VCs disparagingly call "lifestyle businesses". I'm happy that he's been featured on INC, a major US business magazine, even though I'm not enough of a fan to care what kind of tea he drinks and all that.
I'm a fan of Less is More. This year I have been exploring the surprising depth and complexity of this oft-quoted pithy aphorism. Jason Fried is a Less is More poster boy. Except he doesn't like the phrase. I've read it from him elsewhere, but the INC magazine feature reminded me.
If he didn't like less is more because it was overused and therefore overlooked, I would completely understand. But that's not his objection. He says that he doesn't like Less is More because it implies that More is better. Ridiculous!
Actually I worked with a guy who straight-out didn't understand the phrase. In one of his customary rants about inconsequential stuff he confided that he thought Less is More was vacuous and clearly irrational. "More is more and less is less!" he said.
First of all, I think it's obvious why it has a deliberate and prominent paradox. The semantic collision is a key feature of its beauty. Less is More works so well because it identifies the conflict of competing values in a compact and humourous way.
Less [of one thing] is more [of another].
There is an unspoken contex shift in the middle.
So to object to the phrase because it implies that More is better is to misunderstand it on the most flimsy semantic level. Less is better because it is "more good". To advocate Less you must refer to its superiority. Inherent in every word to describe "better" is the notion of "more". It's just words!
So to properly appreciate how well Less is More applies to Jason Fried's own philosophy of software design, you see that (arguably) less features enables something. Something is gained in their place. There is more of something.
Understanding what the two sides of the see-saw are is the critical (dare I say pivotal?) task of applying the less is more wisdom to a given situation. What exactly is the tradeoff being made? This is how I use Less is More in my software development and also in my life.
The opportune moments for the wisdom of Less is More are more specific than just identifying competing goals. It represents minimalism. It's not just less pizza is more beer. It advocates a fresh look at what is essential and rejects overconsumption, overburdening, hoarding and powermongering. It represents a philosophy of happiness and a wholistic goal rather than the pointless pursuit of intermediate tokens that we first world people frequently use as proxies for real goals.
Less is more is a tool for escaping from the distraction of things that are merely a means to an end and resets attention on the end itself.
There are usually hidden tradeoffs in software design and the business of programming. The 80/20 rule (the Pareto Principle) is essentially a variant of this where the see-saw becomes a lever and therefore provides (hold your nose) leverage.
Complexity is befuddling. Complexity in software actually prevents people from getting their work done and often inhibits progress towards their goal. For all it's enabling potential, complex software has an opportunity cost. When I was a kid, I had the justified belief that I could learn any application in one sitting. Those days are long gone. There's a great power to that. Jason Fried seems to be a voice in support of this idea.
I'd like to write more on Less is More. I think the irony is stopping me for now.
