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

http://www.daemonology.net/blog/2007-06-21-think-before-coding.html

by cperciva • 19 years ago

19 16 19 years ago

davidw• 19 years ago

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.

mm• 19 years ago

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.

shiro• 19 years ago

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

brlewis• 19 years ago

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.

cperciva• 19 years ago

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.

webwright• 19 years ago

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.

dood• 19 years ago

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.

Tichy• 19 years ago

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

pg• 19 years ago

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.

brett• 19 years ago

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

ramen• 19 years ago

But, I thought, worse was better? I'm so confused... =)

iloveyouocean• 19 years ago

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.

donna• 19 years ago

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

juwo• 19 years ago

I feel the crux of the matter is: is a bug costly and/or an embarassment?

akkartik2• 19 years ago

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.

akkartik2• 19 years ago

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.

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

Related Stories