182

1.0 Is the Loneliest Number

Filed under: Essays

Many entrepreneurs idolize Steve Jobs. He’s such a perfectionist, they say. Nothing leaves the doors of 1 Infinite Loop in Cupertino without a polish and finish that makes geeks everywhere drool. No compromise!

I like Apple for the opposite reason: they’re not afraid of getting a rudimentary 1.0 out into the world.

I remember my first 1G iPhone. Like a meal you have to wait for, or a line outside a club, the fact that I stood in line for hours made the first time I swiped to unlock the phone that much sweeter. It felt like I was on Star Trek and this was my magical tricorder… a tricorder that constantly dropped calls on AT&T’s network, had a headphone adapter that didn’t fit any of the hundreds of dollars of headphones I owned, ran no applications, had no copy and paste, and was as slow as molasses.

Now, the crazy thing about that release is when the original iPhone went public, flaws and all, you know that in a secret room somewhere on Apple’s campus they had a working prototype of the 3GS with a faster processor, better battery life, normal headphone jack… a perfect everything. Steve Jobs was probably already carrying around one in his pocket. How painful it must have been to have everyone criticizing them for all the flaws they had already fixed but couldn’t release yet because they were waiting for component prices to come down or for some bugs to be worked out of the app store.

Or, I wonder, are they really quite zen about the whole thing? There is a dark time in WordPress development history, a lost year. Version 2.0 was released on December 31st, 2005, and version 2.1 came out on January 22nd, 2007. Now just from the dates, you might imagine that perhaps we had some sort of rift in the open source community, that all the volunteers left or that perhaps WordPress just slowed down. In fact it was just the opposite, 2006 was a breakthrough year for WP in many ways: WP was downloaded 1.5 million times that year, and we were starting to get some high-profile blogs switching over. The growing prominence had attracted scores of new developers to the project and we were committing new functionality and fixes faster than we ever had before.

What killed us was “one more thing.” We could have easily done three major releases that year if we had drawn a line in the sand, said “finished,” and shipped the darn thing. The problem is that the longer it’s been since your last release the more pressure and anticipation there is, so you’re more likely to try to slip in just one more thing or a fix that will make a feature really shine. For some projects, this literally goes on forever.

I imagine prior to the launch of the iPod, or the iPhone, there were teams saying the same thing: the copy + paste guys are *so close* to being ready and we know Walt Mossberg is going to ding us for this so let’s just not ship to the manufacturers in China for just a few more weeks… The Apple teams were probably embarrassed. But if you’re not embarrassed when you ship your first version you waited too long.

A beautiful thing about Apple is how quickly they obsolete their own products. I imagine this also makes the discipline of getting things out there easier. Like I mentioned before, the longer it’s been since the last release the more pressure there is, but if you know that if your bit of code doesn’t make this version but there’s the +0.1 coming out in 6 weeks, then it’s not that bad. It’s like flights from San Francisco to LA, if you miss one you know there’s another one an hour later so it’s not a big deal. Amazon has done a fantastic job of this with the Kindle as well, with a new model every year.

Usage is like oxygen for ideas. You can never fully anticipate how an audience is going to react to something you’ve created until it’s out there. That means every moment you’re working on something without it being in the public it’s actually dying, deprived of the oxygen of the real world. It’s even worse because development doesn’t happen in a vacuum — if you have a halfway decent idea, you can be sure that there are two or three teams somewhere in the world that independently came up with it and are working on the same thing, or something you haven’t even imagined that disrupts the market you’re working in. (Think of all the podcasting companies — including Ev Williams’ Odeo — before iTunes built podcasting functionality in.)

By shipping early and often you have the unique competitive advantage of hearing from real people what they think of your work, which in best case helps you anticipate market direction, and in worst case gives you a few people rooting for you that you can email when your team pivots to a new idea. Nothing can recreate the crucible of real usage.

You think your business is different, that you’re only going to have one shot at press and everything needs to be perfect for when Techcrunch brings the world to your door. But if you only have one shot at getting an audience, you’re doing it wrong.

After the debacle of the 2.0 -> 2.1 lost year of 2006 the WordPress community adopted a fairly aggressive schedule of putting a major release out 3 times a year, and we stuck to it fairly well although in 2009-2010 we’ve slacked a bit, falling into the “one more thing” mentality again. But more fundamentally it’s still shrink-wrap software, which means that updates burden its users in some way so we have to spread them out.

That’s why I love working on web services and pretty much everything Automattic focuses on is a service. On WordPress.com we deploy code to production twenty or thirty times a day and anyone in the company can do it. We measure the deploy time to hundreds of servers and if it gets too slow (more than 30-60 seconds) we figure out a new way to optimize it. In that short rapid iteration environment the most important thing isn’t necessarily how perfect code is when you send it out, but how quickly you can revert if you need to so the cost of a mistake is really low, under a minute of brokenness. Someone can go from idea to working code to production and more importantly real users in just a few minutes and I can’t imagine any better form of testing.

A version 1.0 of this essay appeared in the book Do More Faster. I should also note that Automattic is always hiring.