
"Do it right" is more important than "Release Early" - cperciva
http://www.daemonology.net/blog/2007-06-21-think-before-coding.html
======
pg
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
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_

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

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

~~~
webwright
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.

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

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

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

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

------
donna
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
I feel the crux of the matter is: is a bug costly and/or an embarassment?

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

