Comment by noskynethere
10 years ago
I see a lot of responses that seem to reflect what I consider a misunderstanding of the real advantage of speed.
It's not to get the same amount of work done in a shorter time (the management fallacy referenced in some of the comments).
The point of speed is to increase the number of feedback opportunities. Each feedback datum allows for slight course corrections / confirmation of original hypothesis.
By analogy, think of it like sample size. If you accept time as a primary constraint, then faster iterations (even if you accomplish less!) tend to give you more samples. More samples mean less variance.
Making decisions on a better model (less variance) is very appealing to me.
This article reminds me of one of my all-time favorite articles. Quantity Always Trumps Quality by Jeff Atwood [1]. There is a bunch of commentary on it on Less Wrong [2], some of which is interesting. Also an interesting parallel to a Paul Graham post [3]:
> I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
> For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
1: http://blog.codinghorror.com/quantity-always-trumps-quality/
2: http://lesswrong.com/lw/53e/just_try_it_quantity_trumps_qual...
3: http://www.paulgraham.com/hp.html
Yeah, iteration on an idea is important, so, the faster you complete it (at least MVP) and put out to the world, the better it is.
Its one of the key lessons YC taught me.