Go That Way, Really Fast

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).

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.)

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.

> 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.

"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.