Go That Way, Really Fast(codinghorror.com)
codinghorror.com
Go That Way, Really Fast
http://www.codinghorror.com/blog/2010/09/go-that-way-really-fast.html
11 comments
How do I upvote this comment 5 more times? :)
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).
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.
Why not also throw in libc as well and say it's been over multiple decades?
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.
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.
Microsoft is also quite welcome to use webkit. In fact most everyone would be much happier if they did.
[deleted]
Because libc is universal and does not apply to 'just' browsers but webkit does.
Because the vast majority of difficulty of developing a browser lies in making it able to display the pages that it's browsing correctly.
Well, you could, but every browser relies on (some very similar version of) libc. Not every browser relies on WebKit.
> 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'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.
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.
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.
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! :)
Just another reason webapps are better. No version numbers to keep track of! :)
As another example, Minecraft (recently mentioned on HN) is currently on version 1.1.0 despite still being in its Alpha.
The problem with this attitude:
> 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?"
> 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?"
[deleted]
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.
Misleading abridged title.
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.
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.
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.
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.
Seems like decent enough advice, but I can't help feel that there are going to be plenty of examples of when this fails. Anyone got any?
boo.com.
(Edit: for those too young to remember: http://en.wikipedia.org/wiki/Boo.com)
(Edit: for those too young to remember: http://en.wikipedia.org/wiki/Boo.com)
If you can find it, there's an excellent book on the Boo story; boo hoo http://www.amazon.co.uk/Boo-Hoo-Dot-Com-Story/dp/0099418371
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.
That depends on what you mean by "delayed". :)
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. :)
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. :)
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?
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 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.