The only reason Chrome was developed so fast is because it’s a browser with very little else. Bookmarking sucks, history searching sucks, and it crashes constantly.
Releasing a buggy simplistic product quickly should be not a sign of success but rather a lack of foresight.
I very much appreciated this post…I couldn’t help but laugh aloud and pass the link onto my manager and co-workers. We’re definitely going to check the movie out asap; we hadn’t heard of it, but we’re more than intrigued.
Concerning the post, speed of iteration is greatly important to a successful implementation of a new innovation, especially software, as you demonstrate with examples. I was not familiar with the term prior to this blog post, but the background story is certainly remarkable (and I thoroughly enjoyed your February 7, 2007 post on Boyd’s law of iteration). I linked to your blog from avc.com, a blog I’ve started following of late as I begin my career with a web startup.
I had a few thoughts after reading this post:
When you’re developing, what are the ways in which you encourage a culture within the development team that values speed of iteration above all else? Can the fear of mistakes be overriden? And are their hidden advantages to be implemented, like the effect of hydraulics in the F-86’s superiority over the MiG-15? Our team is small (but growing) and so I’m curious if you had any advice to help us maximize our iteration speed.
“the best browser on the planet” until they unable the development of a NoScript plugin, they’re not.
The problem being that it enables the user to do what they don’t want : stop selected javascript easily by the user (so ads and trackers which are Google’s money-makers).
I believe iterative development makes for a better product. It’s much easier to debug a small number of changes than a large block. But, you must be willing every so often to throw away your code base as cruft will creap in making it much harder to modify. Just look at IE with its Trident rendering engine for an example. I had a boss that believed in agile development. He believed the user got a better experience. At the same time he also believed that it took three major code revisions before you came up with the correct product. That’s not major changes to the UI, he and I believe that those should always be iterative, but a major rewrite of the underlying code.
Some large corporations don’t believe in agile development and use waterfall methodologies because they think waterfall is easier to audit. The problem is that the user often doesn’t get what they need to do their job. These same large corporations often believe that the cost of doing an upgrade is too high so they should do less upgrades. This means that they are often willing to “live” with non-critical bugs which reduces user productivity.
So keep up with a fast iteration cycle, just remember to do a major revamp of your code every so often.
Thanks for the great post ,
I read your article a couple of days ago and i was just reading the Fire And Motion article on joelonsoftware.com (what can I say, I’m just a starter) and i noticed the your strategy seem to be similar to Joel’s Fire And Motion strategy in the part where you have to move forward, specially in these lines :
“Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day”
So I though I would let you know 
Note: (up to this point from the comment i didn’t know that Joel Spolsky is the CEO of SO or the fact that you two know each other, I was reading about the guy and when I saw his picture I was like “I’ve seen this guy’s face before, oh wait isn’t this the guy from the SO team” so i went to the SO team page only to find out that he’s the CEO of SO)