"Do it right" is more important than "Release Early"(daemonology.net)
daemonology.net
"Do it right" is more important than "Release Early"
http://www.daemonology.net/blog/2007-06-21-think-before-coding.html
16 comments
I think no matter how much planning you put into it, you will always make mistakes. Mabye if you release early, you can also discover the mistakes sooner.
And the cryptography stuff was a bad example, I think. Seems to me with proper "design", the public keys algorithm would be a pluggable detail (I mean the actual mathematical algorithm, not the implementation of the whole cryptography system).
And the cryptography stuff was a bad example, I think. Seems to me with proper "design", the public keys algorithm would be a pluggable detail (I mean the actual mathematical algorithm, not the implementation of the whole cryptography system).
The author is right in the domain he's working on, cryptographic security.
For those of us making web sites, we often won't know what "right" is until we put something in front of users.
For those of us making web sites, we often won't know what "right" is until we put something in front of users.
That's true... But you can do your darndest to put something GREAT in front of users... Because the "release early, release often" religion is currently so dominant, it's pretty common to see people release stuff that they KNOW is mediocre with the hopes that their users will help them make it good.
The "... if we did it this way, we could get it out the door in a few weeks.." argument is only sound if what you get out the door is a damn good attempt to solve the core problem in the simplest/most effective way possible.
The "... if we did it this way, we could get it out the door in a few weeks.." argument is only sound if what you get out the door is a damn good attempt to solve the core problem in the simplest/most effective way possible.
You might not know what is "right" until you put it in front of users, but at very least you should know that certain things are "not right". Cross-site scripting vulnerabilities fall into the category of "not right" regardless of what your website is supposed to be doing.
It is ok to not write code for a while, if that works for you. But inactivity can easily breed paralysis, a form of fear of the blank page. And that paralyzing fear of the blank page is far likelier if you're afraid of embarrassment, of forgetting some side issue that will make you look like an amateur (like the reddit guys did). But like in their case, embarrassment is often irrelevant.
Vision is important, yes. Necessary, definitely. But there are subtle feedback loops between vision and action. Just standing in one place is often not the best way to exploit vision. Moving a few steps here and there aids depth perception, and helps vision work better. A lot of the problem in a startup is not technical, a problem to crank through with a single correct answer. The major problem is understanding what users want, the details of interface in the technical area you have chosen. The fastest way to figure that out often passes through a couple of troughs of some criticism and embarrassment.
I think this is a good conversation to have, because it helps us latecomers to unpack the wisdom in 'release early, release often.'
---
There's a subtle fallacy in juxtaposing the phrases 'do it right' and 'release early, release often'. 'Do it right' is a cipher: impossible to use, impossible to criticize. Of course I want to do it right. Who wouldn't? But how should I?
'Release early, release often' gives me advice on how to go about doing it right. We can argue about the value of that advice, but it is inarguably proactive. It takes a stand.
Vision is important, yes. Necessary, definitely. But there are subtle feedback loops between vision and action. Just standing in one place is often not the best way to exploit vision. Moving a few steps here and there aids depth perception, and helps vision work better. A lot of the problem in a startup is not technical, a problem to crank through with a single correct answer. The major problem is understanding what users want, the details of interface in the technical area you have chosen. The fastest way to figure that out often passes through a couple of troughs of some criticism and embarrassment.
I think this is a good conversation to have, because it helps us latecomers to unpack the wisdom in 'release early, release often.'
---
There's a subtle fallacy in juxtaposing the phrases 'do it right' and 'release early, release often'. 'Do it right' is a cipher: impossible to use, impossible to criticize. Of course I want to do it right. Who wouldn't? But how should I?
'Release early, release often' gives me advice on how to go about doing it right. We can argue about the value of that advice, but it is inarguably proactive. It takes a stand.
Imagine an article supporting the opposite "Release Early" is more important than "Do it right". Clearly you could find examples to support either view. YC obviously has a comprehensive startup strategy that includes defaults for many standard behaviors that when combined result in success. Examining some of the downfalls of one of these behaviors out of context with the rest may lead to poor conclusions.
Obviously it depends on what you're up to, but I think that in terms of startups, I'm much more inclined to trust PG's judgement than this guy's. In the article, he cites "40,000 lines of code" as something that was impressive to PG in an interview, and then bemoans the fact that they may have to "throw out and rewrite most of their code". I wonder if that's the same 40,000 of Zenter code that Google might have to rewrite in any case to make use of Google's infrastructure?
He also complains about reddit, but once again - they certainly "made something people wanted" even if it does/did have its share of bugs (clear text passwords...).
This is one of those things that needs to be balanced. You do have to have something that basically works, and doesn't crash all over the place, but sometimes adding new features or doing other things might be more important than making everything 100% bulletproof.
He also complains about reddit, but once again - they certainly "made something people wanted" even if it does/did have its share of bugs (clear text passwords...).
This is one of those things that needs to be balanced. You do have to have something that basically works, and doesn't crash all over the place, but sometimes adding new features or doing other things might be more important than making everything 100% bulletproof.
rewriting code isn't as bad as some would claim. Because the logic of the code has already been set, a rewrite of the app in another language should take no more than 2 weeks. This is esp. true if your app uses an MVC framework where the view template is separated from the logic.
If you can replace the whole system, yes. It's most of the case for early statups where you have only a few developers communicating intimately.
When you write components used by multiple groups, things get far more complicated; you have to provide some stubs so that other party's old code keeps working until they finish migration. Here, at least doing protocol right is essential. (Web app has advantage here, since you can just ride on existing protocols.)
When you write components used by multiple groups, things get far more complicated; you have to provide some stubs so that other party's old code keeps working until they finish migration. Here, at least doing protocol right is essential. (Web app has advantage here, since you can just ride on existing protocols.)
Release as early as you can get away with and attract users.
As more and more people release software, it becomes harder and harder to attract users. The bar on the first release is going up.
As more and more people release software, it becomes harder and harder to attract users. The bar on the first release is going up.
writing a lot of code allows many experiments to be performed.
this is valuable when the problem is not well-defined, or when solutions can't be evaluated until tested on actual users or under partly-unknown real-world conditions.
otherwise he's right, a problem should be studied carefully before any coding, for best efficiency
this is valuable when the problem is not well-defined, or when solutions can't be evaluated until tested on actual users or under partly-unknown real-world conditions.
otherwise he's right, a problem should be studied carefully before any coding, for best efficiency
I feel the crux of the matter is: is a bug costly and/or an embarassment?
But, I thought, worse was better? I'm so confused... =)
He picked a bad example. The guys who wrote 40,000 lines of code in 10 weeks were the founders of Zenter, which just got bought by Google. Most startups would love to do as badly as Zenter.
The reason to plunge in and just start coding is that, as in writing, it helps you to have ideas. But since that initial hacking is mainly a way of having ideas, you should be ready to discard a lot of it. That is just what the Zenters did. They rapidly iterated through a bunch of versions, and that's why by Demo Day they had such cool features to wow the audience with.
The reason to plunge in and just start coding is that, as in writing, it helps you to have ideas. But since that initial hacking is mainly a way of having ideas, you should be ready to discard a lot of it. That is just what the Zenters did. They rapidly iterated through a bunch of versions, and that's why by Demo Day they had such cool features to wow the audience with.
What's more with Zenter is that if you've been paying attention around here, about half their codebase is readily downloadable. It's pretty impressive.
In fact when I heard about the Google acquisition one of the first thing's I thought was: That make sense inasmuch as it just continues the trend of Google's apps being the goto place for learning interesting javascript hacks
In fact when I heard about the Google acquisition one of the first thing's I thought was: That make sense inasmuch as it just continues the trend of Google's apps being the goto place for learning interesting javascript hacks
Reddit's problems are more conceptual: not fixing the recommendation engine and not thinking through the game-theory of their system are the main reasons for Reddit succumbing to the dumbness of crowds so easily.