The entire project is based on Apple's WebKit, which was a cross-platform, arguably best-of-breed browser toolkit on the day they started.

Lars Bak, the architect of V8, has been working on language technologies since the early 90s, including Smalltalk.

A key Chrome team member, Ben Goodger, had already been working on browsers since the Netscape era, and was an early participant in Firefox.

There really are no miracles in software. People used to talk about "Netscape time" or marvel at how Google seemed to come out of nowhere. But even in those cases you can see how prior to those projects becoming household words, they had a long gestation period, during which time they were protected from competition. Netscape included a lot of people from the earlier NCSA Mosaic effort. Google was an academic project that, as an economic entity, grew up in the sheltering shadow of Yahoo.

I'm not saying these people didn't work hard, or aren't brilliant, or don't deserve their success. It's just that whenever you see someone moving much faster than is normally considered possible, don't assume that it's only due to skill. It's far more likely that they had some history of working on the problem, for far longer than you think.

That's obviously wrong. The Chrome beta was over two years ago, and you can bet V8 didn't just appear overnight. Chrome is older than its 1.0. Not to mention that it's based on WebKit, which has been in development for a decade (if you start from KHTML).

To compare its progress with IE's over the last two years is a little dishonest, as many of the things that IE is doing now were implemented in WebKit before Chrome's release. It's essentially writing off a huge stretch of time in Chrome's code's history.

I'm not sure whether the second sentence is supposed to actually contradict the first here, or if it's just a separate, orthogonal assertion (perhaps about technical quality or features)—but if Atwood is really trying to imply that you can iterate toward "tastefulness", that's simply ignorant.

There is a reason that the term "design" exists as a separate and unique idea from "implementation." By looking at your entire problem space top-down, you can see the "shape" of the space, and so head straight toward the global minima. Plopping down in one place and running really fast will just get you to the top of the nearest hill, not the tallest mountain. Google is great at hill-climbing, but I've never seen them start on a hill, realize they were stuck, climb down, and find a mountain. (Instead, Google's successful projects either start at the base of the tallest mountain—Pagerank, Gmail, Chrome, etc.—or are acquired from someone else who has already done the design stage for them—Maps, Groups, etc. It doesn't seem like Android is in either of these categories.)

However, to your point, discarding "tastefulness" as meaningless subjectivity, yes of course you can iterate towards a better, more attractive, more usable user experience.

Anyone who has lived with Android through 1.x on to 2.x and finally to 2.2 would say that many elements have absolutely improved dramatically -- constant usage provides feedback that refines design, while simply having time and resources provides the avenue to implement more advanced UI elements.

And during that time Google has added a number of UI and design experts to the team (again, time and focus: It actually matters now, whereas before they got the core product it didn't). It does seem to be paying off.

They release often yes but the Chrome team recently announced they'll be bumping the major version number for every release now. The version number isn't that significant, its arbitrary.

And really, as you mentioned the whole version number is utterly meaningless. In contrast some open source projects have evolved and changed incredibly over many years and still sit at a sub-1.0 version number. Anyone who would call that slow would be adding superficial analysis noise.

Just another reason webapps are better. No version numbers to keep track of! :)

> So if something gets in our way while doing that, well, we're not gonna fight you. We'll just turn. And keep going forward, really fast. Which is why those clones better move quick if they want to keep up with.

Is that you can gloss over really valuable opportunities because you perceive them as being hard.

Startups get so hung up on releasing features ("we deploy thrice a day!!") for the sake of features, that they forget to ask if they're valuable (and to whom.)

Going for "low hanging fruit" of features works insanely well, but I think eventually you need to stretch your arms else you'll start using the wrong metrics for your company (eg: version numbers as opposed to engagement.)

I see startups all the time not want to compete with better funded / larger companies / better branded companies and shift to do something else, for reasons that can only be explained as lack of confidence / fear of failing at it. a) product markets are rarely winner takes all (Stack Exchange platform is not a winner take all service), b) winners don't win forever (eg: eBay?), c) if someone is that entrenched and you're terrified of attacking them - no one else will dare, so they won't expect it.

Failing (iterating) fast is a great attitude, but only when you change for the right reason. My concern with always changing away from barriers is that eventually you end up with a really dumb proposition, and when you question why it's because you iterated so fast without stopping and thinking "is this good?"

The second sentence of the original advice was, "If something gets in your way, turn." Removing it from the title turns good advice into wrong advice.

Something will always get in your way, no matter how fast you go. So the faster you go the more important Sentence 2 becomes.

Like your race car, when your business doesn't have a steering wheel, things can't turn out well.

If your product managers are clairvoyant you do not need short release cycles. The PMs just tell the developers what kind of features the market will value in, say, three years. The development team is then able to concentrate on building a feature-rich and consistent product without the pressure of producing something quickly and then testing it on the market.

In any other case, you probably benefit from releasing several major versions within a couple of years.

(Edit: for those too young to remember: http://en.wikipedia.org/wiki/Boo.com)

They built the site in an incredibly short time span but they got started too late and it had way too many features to cram in to such a short development time of course leading to plenty of bugs at release time.

The entire company didn't exist for much longer than a year so they almost didn't even have time to be delayed before they were gone. :)

From Wikipedia: "Boo.com's Swedish founders famously spent their way through £125 million ($188 million) in just six months."

Aaah, 1999. Those were the days. :)

Counter examples will be rare because Atwood's entry essentially says "evolve", decorating the post with some ignorance about smartphones, a naive simplification of version numbering, and so on.

Who would argue with "evolve" (insert the obvious joke). His other insight was "adapt", and again...what?

"The Google Android project is another example. Android doesn't have to be better than the iPhone (and it most definitely isn't; it's been mediocre at best until recent versions). They just need to be faster at improving. Google is pushing out Froyos and Gingerbreads and Honeycombs with incredible, breakneck speed. Yes, Apple has indisputably better taste -- and an impeccably controlled experience."

Jeff's judgment on Android versus iPhone is utterly and absolutely irrelevant, and strongly diminishes his post.

Of course the entire post was utterly vacuous (really, top of HN? "Evolve" is now a comment of such insight that it teaches HN something?), so the Android troll was just par for the course.