"Do it right" is more important than "Release Early"

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 xss vulnerabilities in Reddit aren't a great example, since they haven't harmed the service, same for the password fiasco even.

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.

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.

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.

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.

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.

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

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... =)