Super-fantastic-caveat: Despite the title, this post isn’t really about 37signals, in particular. I’ve used them as an example, only. I probably could have called it the “Joel on Software” effect, too. This post is about all of us who aren’t 37signals, or Joel, and the dangers we face when trying to incorporate lessons they’ve learned into our worlds. 37signals is one of the companies I admire most and their book Getting Real should be required reading for software engineers.
For those that don’t know, 37signals is a “web application company” that focuses on “usability, simplicity, and clarity” (quoth the wikipedia). For our purposes, this summary will do well. They are also the authors of the wildly popular blog, Signal vs Noise, and the Getting Real book about their philosophy on business, design, and programming. Oh, and, maybe most notably, they are the birthplace and spiritual leader of the Ruby on Rails project.
37signals is extremely popular because of how freely they give out lessons learned and other assorted advice about software design and the business of software. Each bit of advice has been extrapolated from their experiences. There’s interesting things to be learned from one company’s approach to their situation, but generalizing this to all business is so very dangerous.
When you take a single data point and you try to emulate certain practices to try to reproduce their success, you are entering very dangerous territory. In order to reproduce their successes, you need to understand the attributes that caused that success. Successful organizations have many attributes, but only a few of them really cause the magic to happen. If you don’t make the full effort to understand what is going on, and you just believe imitating some subset is going to reproduce the results, you’ve entered cargo cult territory. If you’ve never read about the cargo cults, I encourage you to go do so. It’s quite entertaining. The 37signals effect is cargo cultism in the business of software.
Let’s make this part very clear: you are not 37signals (well, I mean, unless you are, in which case, hi guys). For everyone else: your application isn’t the same, your market isn’t the same, and your branding isn’t the same. That means every time they extract their experience with their applications in their market and their branding, and try to transfer it to you, it may be completely and utterly terrible advice given your situation.
Every time 37signals gives out advice, there’s this 900 pound gorilla in the room that no one seems to notice. They wrote Ruby on Rails. They have a huge cult following. They have a blog with 80,000 RSS subscribers. Do you? The next time you read some of their advice ask yourself if it makes sense for them only because of all these things you can’t reproduce. I’m pretty sure there isn’t a chapter in Getting Real that says “First, write and release one of the most important and popular open source projects of the last 10 years”. But should there be?
Conventional wisdom says that to beat your competitors you need to one-up them... This sort of one-upping Cold War mentality is a dead-end... So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else.
So while I consider Getting Real to be an altogether fantastic read, this particular advice can be downright lethal. I know you want it to be true. I know you want to believe this is the secret to 37signals success. It’s not. Even if they say it’s the reason for their success, they are wrong. It’s not. The vast majority of people get paid money precisely because they solve hairy, difficult, and nasty problems. People who solve easy problems are a commodity. French-frying a potato is an easy problem.
Doing 20% of the work for an 80% product, and solving only the easy problems, brings certain consequences. When you are 37signals, you have some other advantages, as well. The follower, however, isn’t so lucky. He is stuck with just the consequences, and none of the advantages.
So you decide to sit down, following the philosophy of minimalism and write your own application. You do 20% of the work and get 80% of the product, just like 37signals preached. You start charging money and maybe even start profiting. But all the sudden you have a huge problem. Because you did so …little, and solved a problem that was so easy, you have competition coming out of the woodwork (because any goofball can replicate what you’ve made in a week with a Jolt-induced marathon). And then one day a company we will call Moogle, comes out with some new nifty Application Platform and decides to code up some demo apps. Since your app is so absurdly minimalist (if minimalist is good, absurdly minimalist is better!), using their powerful new tools, a couple of guys at said company are able to clone (possibly inadvertently) your app in a few hours of their spare time as a demonstration. Let me repeat that: your product was so minimalist that it just got “stolen” by another company as one of their sample apps.
Now, if you are 37signals when this happens, you have 80,000 subscribers and a huge brand name. You can complain that you’ve been copied. You can get quite a bit of press, and bunches of bloggers crying foul. You can make a big stink in the media. You can posture about being copied and question the big company’s core values. In the end, you can make a big PR problem for the big company who doesn’t particularly want to fight that fight and so relents and takes it down.
But you aren’t the leader. You are just one of the followers. You don’t have 80,000 subscribers. No bloggers will notice that you’ve been copied. No one will be writing articles or quoting your opinion in their publication. Now what? It’s probably time to get to work on those difficult problems and start adding features.
