The first meetings about Chrome were held in 2006.
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.
Only if HN were to give members a fixed number of upvotes per original posting -- or per day, hour, week, etc. -- and let the members dispense those upvotes as they see fit. See http://en.wikipedia.org/wiki/Cumulative_voting#Use.
Google went from nothing, no web browser at all, to best-of-breed in under two years
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).
While I agree with most of Jeff's sentiments - I do have to diverge on marking how fast software moves by something as arbitrary as a version number. Something such as versioning is completely ad-hoc and should not mark the advancement/maturity of a software product. How long did VLC take to get to version 1.0? That does not mean their development/release cycle is any slower than Chrome's. Perhaps I am being a bit drastic here, but it appears to me that judging software iteration speed by a version number is almost as lame as marking a programmer's efficiency by the number of lines of code he writes in a business day.
That jumped out at me also as a completely wrong-headed statement. To paraphrase Newton, they were standing on the shoulders of giants when they started.
I'd take issue with his other premise as well. Though I suspect he's on a different operating system, Chrome on Mac OS 10.5 seems to be an insufferable memory hog.
Chrome was built for Windows. Mac OS X was not supported until Version 5. Why use Chrome on Mac OS X when there's another good Webkit browser there by default?
"Good" is relative. Compared to IE 6, Safari for Mac is great. Compared to Chrome, Safari is annoyingly slow. Chrome never just locks up the way Safari does.
Yes, why not. My point is that Chrome has no clear cut "starting date". It's the culmination of multiple teams over multiple time periods.
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.
> Yes, Apple has indisputably better taste -- and an impeccably controlled experience. But at their current rate of progress, they'll be playing second or third fiddle to Google in the mobile space inside a few years. It's inevitable.
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.)
I am not even sure what the second sentence means. Google no longer produces phones. Was it about OS? Then how do you compare order of the fiddles? By market share? Makes little sense. By revenue? Makes no sense in this case. By customer satisfaction?
iOS progress it tightly coupled with hardware: iPhones, iPad, iPod touch.
Android progress is handicapped by carriers — how do they push updates to handsets.
The whole paragraph is a meaningless orthogonal assertion. Jeff wanted to say "look at how Android has progressed", but somehow go waylaid into defending his historic strong iPhone bias, destroying whatever example he might be making.
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.
Is Jeff actually using the version numbers of Chrome as evidence of how fast they move?
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.
It seems that they're racing to get to 9 for "version parity" with Internet Explorer.
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.
That may be true. But this is a good example of something that means one thing to programmers, and another to customers. We know version numbers are meaningless, but I'm guessing most people would put down software version 0.3, because it doesn't sound good. Come to think of it, I would also prefer a version 10 over a version 0.6, even if consciously it makes no sense.
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?"
It's OK to iterate fast if there are few/no dependencies on the platform and the cost of upgrading is low. e.g. the high-end 3D gaming market is essentially dead as a business because consumers eventually got wiser about today's top-of-the-line 3D card becoming commodity chips 6 months down the road.
Even though Atwood refers to version numbers as (false) indicators of progress, he has an important point: the earlier you release, the sooner you'll be able to make crucial corrections.
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.
I don't remember exactly how Boo.com went up and down, but wasn't the site extremely delayed? Atwood seems to talk about release early, release often (go fast, turn) and Boo.com, in my memory, did just the opposite.
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."
It's vacuous, obvious advice. That Atwood tops HN with such tripe has always been a mystery to me.
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 whole post went off track, and fast, when Jeff had to trollishly add in the Android bit near the end--
"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.
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.