http://ma.tt/2010/11/one-point-oh/

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.

“Real artists ship.” — Steve Jobs, 1983

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