programming and human factors
by Jeff Atwood
When it comes to running Stack Overflow, the company, I take all my business advice from one person, and one person alone: Curtis Armstrong.
More specifically, Curtis Armstrong as Charles De Mar from the 1985 absurdist teen comedy classic, Better Off Dead. When asked for advice on how to ski down a particularly treacherous mountain, he replied:
Go that way, really fast. If something gets in your way … turn.
(I recommend watching the video clip, or, better yet, the entire movie. It's brilliant in ways I can't possibly explain here.)
In the five months since we announced our funding, we have …
… and honestly, I'm a little worried we're still not going fast enough.
There are any number of Stack Overflow engine clones out there already, and I say more power to 'em. I'm proud to have something worth copying. If we do nothing else except help lead the world away from the ancient, creaky, horribly broken bulletin board model of phpBB and vBulletin -- attempting to get information out of those things is like panning for gold in a neverending river of sewage -- then that is more than I could have ever hoped for.
It is our stated goal as a company to live in harmony with the web, by only doing things that we believe make the internet better, at least in some small way. No, seriously. It's in writing and everything, I swear! We're not here to subvert or own anyone or anything. We just love community, and we love getting great answers to our questions. 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 us.
While I like to think that having Charles De Mar as a business advisor is unique to our company, the idea that speed is important is hardly original to us. For example, certain Google projects also appear to understand Boyd's Law of Iteration.
Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.
Speed of iteration -- the Google Chrome project has it.
| 1.0 | December 11, 2008 |
| 2.0 | May 24, 2009 |
| 3.0 | October 12, 2009 |
| 4.0 | January 25, 2010 |
| 5.0 | May 25, 2010 |
| 6.0 | September 2, 2010 |
Chrome was a completely respectable browser in V1 and V2. The entire project has moved forward so fast that it now is, at least in my humble opinion, the best browser on the planet. Google went from nothing, no web browser at all, to best-of-breed in under two years. Meanwhile, Internet Explorer took longer than the entire development period of Chrome to go from version 7 to version 8. And by the time Internet Explorer 9 ships -- even though it's actually looking like Microsoft's best, most competent technical upgrade of the browser yet -- it will be completely outclassed at launch by both Firefox and Chrome.
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. 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.
So, until further notice, we'll be following the same strategy as the Android and Chrome teams. We're going to go that way, really fast. And if something gets in our way, we'll turn.
Fast iteration is what in the end gets the best results (if backed by constant revision!). It is like continous improvement: http://www.mostlymaths.net/2010/05/doing-your-best-8-tips-on-continuous.html for one-man (or woman) projects, only in a big scale
Ruben
Berenguel on September 12, 2010 1:29 AM"If everything seems under control, you're just not going fast enough."
Mario Andretti
see also: http://www.quotationspage.com/quote/36794.html
Yeah it really is amazing how Google built Chrome from scratch in only 2 years. I can't imagine how they did it they must be so clever. And new major versions every few months - WOW! Each new version is so much better than the previous it's incredible. Now that they are up to verison 6 they are nearly as good as IE which is at version 8. Insightful stuff Jeff.
Davidheff on September 12, 2010 1:59 AMGoogle went from nothing, no web browser at all, to best-of-breed in under two years.
To be fair, Google did not go from exactly nothing: By choosing the Free Software road, they were able to take advantage of the years of developement put into KHTML/WebKit by the KDE (and later, Safari-) developers.
asjo on September 12, 2010 3:09 AMI think Joel already wrote about this :) fire and move. Fire and move. Fire and move. Fire and move
John Ferguson on September 12, 2010 3:47 AMGoogle isn't fast with improving Android, not where it counts anyway.
The paid Android Market is limited to a handful of countries that doesn't include mine for example (Estonia). Apple had the app store working within months after its US release, but google hasn't even announced any plans and it's been 2 years since its launch.
Google has made it clear from the beginning that they handled and mastered their software release cycle through agile development practices and other SCRUM related jazz; That's not a big news. Seeing it in action, is big news. Moreover one may argue that having someone good to catch (iPhone, IExplorer, Firefx, Java Browser...) makes it an even better / motivating project.
Eventually what I mean is : Google has the ressources to go fast while not doing big mistakes.
It's a lot easier to develop a product once the user testing has been done for you. You already know what users want. Being the 60th software package within a certain genre means you can go really fast.
David Harris on September 12, 2010 5:50 AMGoogle have enormous pools of talent at their disposal. It's pretty easy to move fast when you are driving a sports car.
j_col on September 12, 2010 8:21 AMLove the movie reference. I agree with the approach btw, with one extra caveat - stay focussed and try to keep your goal in mind. Going fast to some people means piling on more and more features in shorter and shorter cycles until you overwhelm your customers and your ability to provide support to them. Chrome seems to have succeeded because they've included a heavy dose of refactoring into their cycles.
FWIW I'm concerned that StackOverflow has piled on too many features / options - I no longer know which of the 24 sites I should visit for my question, I don't know or want to think about which OpenID provider I want to use - I don't know if my ID on one stackoverflow site is the same on all of them, does my reputation apply across all sites, etc.
I keep trying - because I like the concept, but it seems to be getting more complicated, not easier to use...
Ddelmoli on September 12, 2010 8:42 AM"ancient, creaky, horribly broken bulletin board model of phpBB and vBulletin" -- I am sure you must have written tons of articles before about this... Can anyone point me in the direction of such explanations?
Francesco Gallarotti on September 12, 2010 11:25 AMWhen most people step on the accelerator to go faster than everyone else, they get a speeding ticket, or end up distributed across the freeway in bite-size pieces.
Going faster can be a definite win, no argument there, but make sure you're driving a frikkin' Ferrari F1 on a closed circuit, with damn good brakes, back-up engineers and no 3-year olds playing Cops and Robbers in the pits!
I can't even begin to describe the number of software projects I've been on that have hit a 3-metre thick reinforced concrete wall at 250kmh.
The turning is the important part. Running faster or slower depends on what kind of race you're in (marathon, 100m). Of course, the terminology is different: when you are going slowly, it's not really a turn, it's more like a jump. The important thing is to leave the good ideas of the past behind, and not reminisce.
More on that: Jumper
Speed of iteration -- the Google Chrome project has it.1.0 December 11, 2008
2.0 May 24, 2009
3.0 October 12, 2009
4.0 January 25, 2010
5.0 May 25, 2010
6.0 September 2, 2010
I'd call that "speed of version number inflation" more than speed of iteration. The current build is hardly akin to a 2.0 release. Still impressive, but calling it "6.0" implies 6 major design variations, and IMHO does the project a major disservice. They have stayed the same course the whole time, and have a good product to show for it.
In any case, yeah, fast iterations are important when your customer base is geeks of the world. They understand and overlook imperfections. I don't think you're as right about Android/iPhone though. Google is making significant progress there, but they are also accruing some significant technical debt and their triple user bases (carriers, manufacturers, then customers) keep them from servicing that debt at any manageable rate. They will need to "turn" soon, and momentum has a funny way of upending vehicles which turn too quickly.
How long it took for Google to get version 1.0 out?
TBH I'll rather get a stackoverflow CMS, even a paid one (like vbulletin) than dealing with clones.
And I wouldnt use google's products as an example, since anyone could do amazing stuff if surrounded by some of the best engineers in the world and a budget numbered in the billions.
Mozilla with its lack of income and stand-alone platform is way more impressive: Firefox4 runs way faster than chrome does in my PC
You have come a long way from your initial view on android which was, (from memory) "it has about as much change as linux on the desktop."
A blog entry about why you were wrong, and what google did with android which has made it so successful would be an interesting read.
Daniel Hughes on September 12, 2010 11:21 PMThank you for this post it is very great and I like it because it has special value in my culture. I was trying to mention some things which are import to startup building process: http://www.arekskuza.com/index.php/2010/07/think-global-start-up-in-poland/.
I think speed influence young companies the most. Also, speed comes from motivation, culture and vision. This is kind of hard to build in 9-5pm work culture. You mentioned very important point.
Arek Skuza on September 13, 2010 1:42 AM"If we do nothing else except help lead the world away from the ancient, creaky, horribly broken bulletin board model of phpBB and vBulletin -- attempting to get information out of those things is like panning for gold in a neverending river of sewage -- then that is more than I could have ever hoped for. "
Just because a product doesn't meet your needs doesn't mean the product doesn't meet the needs of someone else. phpBB and vBulletin are good for holding conversations, but not at Q&A.
Similarly, StackExchange is good for having Q&A, but not good for conversations.
You seem to be aware that SE isn't good for conversation, as you in turn added chat to Meta.SO... chat rooms which looks suspiciously like a non-threaded bulletin board system (i.e. phpBB) topic masquerading as a real-time chat.
Powerlord on September 13, 2010 8:21 AMThe 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.
Josh Kehn on September 13, 2010 8:57 AMI remember that movie, things were a lot simpler back then.
http://www.cleansingsite.info/627/do-i-need-a-parasite-cleanse-how-do-remove-parasites
CleansingSite on September 13, 2010 12:25 PMI 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.
Abl3030 on September 13, 2010 1:34 PM"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).
Arkh on September 13, 2010 3:32 PMvery nice, i like your blog
astrologie
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.
Tannyo on September 14, 2010 11:05 AMThanks 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)
--------
I decided to keep the comment unchanged so that everyone reading this can enjoy some laughter moments.
I'd argue "improving fast" does not inevitably lead to "eventually dominating."
Your two Google examples make this point well. It's clear that Google Chrome translates speed of development to domination, but that's because what's a good browser is pretty well established, there's a good foundation, and the direction seems pretty clear (support the new web applications --- as opposed to the old web pages --- better).
Google Android seems like a much more dodgy claim. The problem is that Google Android has no strong central personality like the iPhone or like Google Chrome. So it doesn't have a strong sense of identity, and I think there's a real good chance that the direction is just wrong. Google Android could win, or it could turn out to be the linux of the mobile space. Yes, linux dominates for servers, but as an individual PC OS, it's a perpetual also ran. Even if Ubuntu goes like a bat out of hell, I doubt it will ever give MacOS much to sweat about. There's no central focus to ensure that all the effort poured into Linux (or Google Android) will end up fixing the problems with the user experience. There's been a ton of time poured into linux, and some totally excellent stuff has been produced. But plugging a new peripheral in is still likely to be a horrid experience, your laptop is still likely not to hibernate properly, you may have to jump through hoops backward to get the wifi to work, etc.
Chris De Mar didn't just say "go really fast," he also said "go that way." If you can't tell this way from that way, going really fast isn't going to help.
Robert Goldman on September 14, 2010 1:50 PMGoogle is pushing out Froyos and Gingerbreads and Honeycombs with incredible, breakneck speed. 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 agree with Robert Goldman that this seems like a dodgy claim. Not just for the reasons he cites, but because it completely omits the role of the carriers.
Marijane on September 14, 2010 2:20 PMDoes it sound only to me, like it is doing speed just for the sake of doing speed? Shouldn't iteration be something focused mainly on improvement?
If speed is the motivator it may be that you do iterations for things which would not be worth to make a new version. Ending up in "senseless" versioning. Just to show that you are fast.
It should stay like you iterate for improvements and of course you will not be afraid to go fast if you have a lot to improve and like to do it in smaller steps (not to let someone wait too long for an important feature).
And I would not compare software iteration with car racing. Because at car racing exceeding the limit of control might end lethally.
Juergen Szolay on September 15, 2010 1:52 AMIterations can also be done for refactoring. Unless of course, nobody wants to clean the code up.
I'll have to wait and see if the Android claim comes through through. The IPhone is so successful because Apple made it easy to develop and distribute applications, if one has a Mac. In a sense, the third party application developers helped make the IPhone more useful and more adaptive to the needs of the IPhone users.
Google has to match that at the very least. At the very least, developing for Android doesn't require a specific computer.
Lie-siu.blogspot.com on September 15, 2010 12:48 PMChrome was my favorite browser from the moment it came out. Sure, it used an outdated rendering engine (Webkit 3 I think), and sure, it had no support for extensions and whatever. It did have great performance though.
But most importantly, it had by far the best user interface of any browser. Dragging tabs to other windows is absolutely brilliant, and not indicating the operation with obscure arrows, but directly, makes it complete.
No other browser I've seen can claim this. And now, Chrome does support all the ultra popular features I never use anyway.
Joren Vermijs on September 15, 2010 5:05 PMChrome is my favorite browser and thanks to Google for the new version. I think they have a good team of great minds and they know how to play on the pitch of internet world.
Ajkbagh1 on September 17, 2010 2:12 AMOr, to quote Jim Seymour from way back in the 1980s: "Anything worth doing is worth doing badly."
He made essentially the same points you did. You're in good company!
Skip Knox on September 17, 2010 9:01 AM@Lie-siu.blogspot.com
Even if the Google folks get their Eclipse-based development environment up and excellent, I think there are still a bunch of reasons why the iPhone might win:
1. The environment to which you develop is not well controlled. Unlike with the iPlatform, you don't have a clue what hardware you're going to find yourself deployed on. As far as appearance is concerned, this is as bad as writing software to run in a browser, and I think we've all had browser experiences where the author's expectation of our window size is just horribly off what we actually had. Plus you have to worry about all the possible hardware variations (with camera, without camera, with gps, without gps, with keyboard....).
2. There is no unified user experience. Even within the suite of software Google supplies, I am never sure whether that button I need to press is going to be on the menu or down at the bottom of the menu. I'm never sure how gracefully the keyboard will work as an alternative form of input, etc.
3. The Android Market. If you've used it and iTunes, then you know how horrible this is. Yes, it's all open and wonderful that way, but it's like shopping in a bazaar in a country that has inadequate consumer protection. Only without the charming interpersonal interaction.
4. The OS upgrade process is hell (if you have upgraded both an Android device and one of Apple's, you know what I mean). This is largely because
5. There is no iTunes. Yeah it's a walled marketplace. But it's also a reliable desktop synchronization tool. Android bets that those are unnecessary. I don't think so....
Some of these can be dissolved by iteration, but others... nope. It's like hoping that GNOME will eventually turn into the Mac Desktop. That will never happen. For my compute servers, I can live with GNOME or KDE. For my day to day work, I'll take Mac OSX in a heartbeat, and I don't think any number of KDE or GNOME releases will change things, no matter how fast they come.
Robert Goldman on September 17, 2010 2:32 PMI'm not surprised that Google, as a company, can innovate at the speed of lightning compared with the incredibly slow pace of the clunky old Microsoft. The former has grown up developing for the web, where updates can be released several times a day. The latter grew up writing shrink-wrapped software, released every three years or so. That puts Google's speed of iteration about one or two THOUSAND times greater than Microsoft's. Granted, those iterations include far, far smaller changes, but that's the whole point: small improvements done quickly are much, much better than big improvements done slowly since turns can be made so much more often.
Bobbykjack on September 22, 2010 5:21 AMTo be fair, it is more like shipping faster then they are actually very fast at developing.
Chrome uses Webkit, Andriod uses Linux, both took YEARS before they get mature to a state that is used by Google. of coz google did a fair bit in JS engine V8. But it is nothing compare to a gigantic work of Webkit.
Edward Chick on September 23, 2010 7:04 AMJA wrote: "We're not here to subvert or own anyone or anything. We just love community"
Yeah, right. And just how much of that Love (money) are you sharing with the community? Specifically, monetizing the QA sites that come out of Area 51.
It's a great model, really. Get people to propose ideas. Have them do all the legwork to build interest. If it looks like there might be interest, beta the site. If it hits critical mass, then bingo! We have a winner. If not, oh well, we didn't do any work anyway.
It looks like it's going to be quite successful, so props to your team. I just don't understand why people don't see Area 51 for what it is.
Kevin Powick on September 25, 2010 7:18 PM"open, democratic process for creating Q&A sites at Area 51"
Yeah, right. That's why one person can close the proposal.
http://area51.stackexchange.com/proposals/2868/apocalyptic-defense
I just discovered your blog today, and slowly realised that you were the person behind the stack exchange family of sites. Thank you so much for these resources, they have helped me hugely with R, general programming, LateX and Ubuntu. Thanks.
Richard Morrisroe on February 2, 2011 11:44 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |