"Simplicity, not Simplistic: 1" by smeade

Wed, 13 Dec 2006 22:19:00 EST

Following up on his famous Ruby scaling debate, Joel Spolsky, takes another shot at 37signals and other propenents of simplicity saying that “you sell ‘simple’ as if it were this wonderful thing, when, coincidentally, it is the only thing you have the resources to produce.” Even if it were true (which I do not think it is) that companies selling ‘simple’ do so when they have reached the limits of their capabilities, it would not follow that simplicity is a poor strategy.

Among Joel’s reasons for avoiding ‘simplicity’ as a strategy are that you will be easily copied and that the “weaknesses as strengths” approach is not sustainable.

Low Competitive Barrier to Entry

In believing that you are toast when competitors come in and easily copy a “simple” program, Joel forgets that the software itself is only a small part of a company’s success. This is why you see posts like Code is 5% of your business and 10% of this business, on the outside, happens in the IDE. The other 90% is where you make your money.

For twenty years, software has been a relatively easy business to enter. No one should think they will not have competitors and copycats in this business, no matter how small or large your code base.

Innovation

Joel also discounts the ability to “use your weaknesses as strengths” as a long term strategy. While Joel thinks that is true, I believe that building a company strategy around having more features than the competition does not work in the long run.

I like books that are empirical studies of companies, not authors trying to advance a pre-determined platform. One such book is “Built to Last” by Jim Collins. Among the hundreds of findings in Built to Last, two are especially relevant here.

Collins: Most successful companies do not exist first and foremost to maximize profits.

Collins: Most successful companies do not focus primarily on beating their competition.

My Take

Do not focus on having more features than your competition. Do not add a feature just because you think it might bring in short term profits. You need to primarily consider the potential long-term impacts to customer satisfaction. Customer satisfaction and your ability to produce raving fans for your products has been shown to be negatively impacted over time when a product is more complex.

While Joel seems to discount these findings (and he certainly has more experience running a company than I do), I believe that this approach will work for Synap Software and our customers.

Synap Software comments on Simplicity, not Simplistic: 1

"Simplicity, not Simplistic: 1" by smeade