14 KiB
| created_at | title | url | author | points | story_text | comment_text | num_comments | story_id | story_title | story_url | parent_id | created_at_i | _tags | objectID | year | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009-10-13T19:25:03.000Z | Release Late, Release Rarely (2006) | http://www.aaronsw.com/weblog/rlrr | alexandros | 55 | 32 | 1255461903 |
|
879867 | 2006 |
Release Late, Release Rarely (Aaron Swartz's Raw Thought)
Raw Thought
by Aaron Swartz
Release Late, Release Rarely
When you look at something you’re working on, no matter what it is, you can’t help but see past the actual thing to the ideas that inspired it, your plans for extending it, the emotions you’ve tied to it. But when others look at it, all they see is a piece of junk.
You only get one chance to make a first impression; why have it be “junk”? Once that’s associated with your name or project, it’s tough to scrape off. Even people who didn’t see it themselves may have heard about it second-hand. And once they hear about it, they’re not likely to see for themselves. Life’s too short to waste it on junk.
But when you release late, after everything has been carefully polished, you can share something of genuine quality. Apple, for example, sometimes releases stupid stuff, but it always looks good. Even when they flub, people give them the benefit of the doubt. “Well, it looks great but I don’t really like it” is a lot better then “it’s a piece of junk”.
Still, you can do better. Releasing means showing it to the world. There’s nothing wrong with showing it to friends or experts or even random people in a coffee shop. The friends will give you the emotional support you would have gotten from actual users, without the stress. The experts will point out most of the errors the world would have found, without the insults. And random people will not only give you most of the complaints the public would, they’ll also tell you why the public gave up even before bothering to complain.
This is why “release early, release often” works in “open source”: you’re releasing to a community of insiders. Programmers know what it’s like to write programs and they don’t mind using things that are unpolished. They can see what you’re going to do next and maybe help you get there.
The public isn’t like that. Don’t treat them like they are.
You should follow me on twitter here.
July 5, 2006
Comments
I’m a bit confused about this post. It seems like it is in stark contrast to the strategy taken with Infogami. Am I missing something? The thinking there seemed to be release something very early, and incrementally improve it with feedback from the public. Or do you consider those early users “experts”?
http://infogami.com/blog/introduction
posted by confused on July 5, 2006 #
I tend to disagree. It’s better to get something out there that solves some demand and works reasonably well.
Apple is a bad example on both sides of the spectrum: 1) it’s released stuff early that doesn’t work very well and 2) it’s really not a good proxy for anything in the first place. Neither is Microsoft.
posted by pwb on July 5, 2006 #
Is this something you feel you’ve learned with Infogami? Or another of your projects? I’d like to know what inspired this thought!
Do you think that if you can tough it out then perhaps “Release Early, Have A Thick Skin, Come Back With Something Better” might be a good strategy? It’s the taking of the criticism and using it to improve the thing that can be tough, or impossible.
posted by Thomas David Baker on July 5, 2006 #
There were a lot of different things going on with infogami that helped force my hand, but if none of those existed and I had the chance to act again, I’d probably follow this strategy.
I don’t think having a thick skin helps. The problem is not that your feelings get hurt, it’s that your reputation does.
posted by Aaron Swartz on July 5, 2006 #
This reminds me of this essay by Joel Spolsky, http://www.joelonsoftware.com/printerFriendly/articles/VC.html where he talks about the rate of growth of various things, and discusses several failure modes of the form one outpaces the other, including this one, where PR outpaces quality of code.
posted by Douglas Knight on July 5, 2006 #
Perfect is the enemy of done.
posted by PJ on July 6, 2006 #
Dualisms are easy, especially to initiate discussions… early/late, high/low, public/private, programmers/non-programmers… these are generalizations one should really try to understand and then finally give up on. Zenish
posted by Tommi on July 7, 2006 #
Eh? Then again, Microsoft likes to release stuff that’s junk and that doesn’t look good. And Microsoft’s still as big and bad as ever.
posted by bi on July 7, 2006 #
Aaron, I wonder what would happen if you posted your “Release Late, Release Early” article on Auran’s TRAINZ Simulator web site? People have been complaining that SP1 is way overdue ever since the 2006 Edition came out.
(Personally, I feel that good things are worth waiting for - although I also use agile approaches when appropriate. Perhaps the key is having a toolbox that includes both ends of the spectrum combined with the wisdom of when to use each.)
posted by Russ Schwartz on July 7, 2006 #
You can’t really compare Apple to a smaller development firm who’s using agile practices. Apple has tons of developers for each project, all of which work in concert towards one goal. If you’re using agile development, the release early/release often isn’t that you release your product to customers which would purchase it out of your web store in that state. You release software to your client (i.e. someone who comissioned a piece of software or someone that has a specific, urgent need for that software that you will be selling). I don’t think any software house would ever release something they knew wasn’t polished enough for release and expect it to sell. I do think they would release something that is polished and usable with the expectation of improving on it (which, one could argue, is the Apple Way), but never something they knew was a pile of crap.
posted by Jeremy McAnally on July 7, 2006 #
infogami is full of “barely started” wiki’s. This is party because its soo half-baked. It just downt provide some of the tools necessary to build the kind of sites it claims to help build. Now if you had released the source, others would’ve (maybe) contributed and offered suggestions. tbh infogami generated much exitement, because there are many who need a good bliki. but one which would work with third party tools (metaweblog/blogger API??), maybe google sitemaps, paid features (space for images,db,webpy scipts) etc. as for apple software dev, read mark pilgrim switch story.
posted by Deidre on July 7, 2006 #
The comment on Microsoft was the DUMBEST one on this page.
The fact is that Microsoft makes products that can be used by the average human being and not something that only techno-weenies can use.
The proof is in the pudding — what is microsoft’s market share in the OS market?
posted by du on July 7, 2006 #
Releasing early & often means you get a reputation for producing concrete things & for constantly improving them.
Releasing late & rarely means that you get a reputation for vaporware & that your products almost always disappoint the customer (or investor). (Who notices every little flaw.)
Unless you have the resources to develop a complete, polished application without having to hype it up to potential customers or investors…
In my experience, even non-technical customers will respect you—in the long run if not before—if you develop a reputation of regularly delivering improvements.
Indeed, look at Apple. Mac OS X, iLife, the MacBook Pros…they’ve released stuff that was half-baked, but they’ve also developed a reputation of constant improvements.
Yeah, they get the pretty in up-front, but that’s relatively easy. (& creates the old problem of the manager/customer thinking the application is close to being feature complete simply because the UI looks complete.)
posted by Robert Fisher on July 7, 2006 #
I see a good case for having your first release as late as your funding and competitiors will allow. But once you have a community of users to support, you need to support them with timely improvements.
posted by Dvd Avins on July 7, 2006 #
When you talk of suburban population, you said you don’t have sympathy for them but they can’t be blamed, because they weren’t the ones who put themselves into that bandwagon.
But when it comes to ‘public’ from the standpoint of ‘set up by my father’ or ‘well, by all means, I’m very talented’ computer geek, you just put down ‘public’.
Usually if it’s this segmented, you need some emotional experience to follow through bit more and connect things in your head bit more.
Douglas Engelbart really didn’t have much vision for putting computation in public use. He thought about probably layered, and porous model. Experts first use it but experts would be public-issues minded, so they’d make something good for public (this is my asumption.)
Steve Jobs looked at Xerox Parc’s system (Alto?) and then later said he kind of made mistakes at just introducing only GUIs to public - and couldn’t take in ideas like network, teamwork with PCs. He tried to make excuse for utterly failing delivering ‘the system’. (and now sells ipods and stuff…) He just makes money out of public.
We don’t even know how he use Apple machines and softwares to be really creative. Does he program? Ouch. Aaron. He doesn’t. And probably he won’t even he had 5 or 10 years of free time in his life. He’d have better things to do in his limited life time…What this means? (I’d be surprised one day Apple release how Jobs use computers…in genius way…)
Alan Kay (according to Howard Rheingold?) said Doug’s system was too complex for him, so he went for Logo/Squeak apporach of popularizing computation among human population.
And I know - I think I know, even open source world’s people or freeware people don’t really look into these episodes. Despite the root fact that we probably owe much to more ‘integrated’ figure such as JCR Licklider, who worked for actualizing internet and PBS(Narrow Cast System?) - ethos and history of 20th century American tech&sci communities.
True, things become diluted, and thiner and often it’s even hard to find the way back to its roots, or springs.
posted by a.kusaka on July 7, 2006 #
Infogami failed because you released early, but then failed to release often. People saw it and tried it early on the assumption that it would get better, and then you let it flop. What you should be saying is that one shouldn’t release early and then forget about it, because then people will remember you for releasing an alpha product, having people try it, and then abandoning it.
posted by on July 8, 2006 #
Very nice. It is so hard though in this fast paced world. We live by speed. But, I agree with you. What if we all live to 75-80 and spent our time on 2-3 of our favorite projects. Can you imagine what kind of quality we could generate? We would be considered Picasso’s or Da Vinci’s. But, I am sure many of us start a project, work on it for a month and then we are bored with it. Even from a business perspective; we may see interest in a project for a while but to really turn something into quality. It seems like a rare thing these days.
STEPHEN R. COVEY and his habit books have some things to say about this. To your original comment, it is all about mental programming. And some of us have some bugs in that regard. Me being one of them.
posted by Berlin Brown on July 8, 2006 #
Re vaporware: I didn’t state this explicitly, but I was assuming you didn’t publish any details about what you were doing until you released.
posted by Aaron Swartz on July 10, 2006 #
Re vaporware: But my point was that in the software business—at least for most of us—you have to give details to somebody before you’re ready for a release. Having a good reputation with your investors is as important as having a good reputation with customers.
posted by Robert Fisher on July 13, 2006 #
You can also send comments by email.
| ----- |
| Name | |
| Site | |
| (only used for direct replies) | |
|---|---|
| Comments may be edited for length and content. |