

Diary of a Failed Startup - nostrademons
http://diffle-history.blogspot.com/

======
kaens
"Solve a problem, not a class of problems."

I, for one, think this is good advice for code in general. At least "at first,
solve a problem, not a class of problems".

I have noticed that if I write my code too general at first, it ends up
solving one class of problems kinda poorly, and ends up being re-written. If I
write it for the specific problem I need to solve, and then generalize it to
include another similar problem when I need to (and continue this process), I
end up with very solid generalized code that solves a specific class of
problems very (IMO) elegantly. It still gets re-written, but in a small-chunk
iterative fashion.

This, of course, may be because of the way I think - or it may be due to me
being relatively "young" as a developer. I am slowly generating more general
purpose code that is getting reused for similar problems in different
applications, however I write much more code for specific problems than I re-
use.

Perhaps someone who's been doing serious coding work for more than a few years
would like to weigh in on this?

~~~
llimllib
I've always liked the rule of three; the first time, solve just your immediate
the problem. The second time, notice that you solved the same problem twice.
If the same situation occurs a third time, write a general solution.

~~~
eelco
I couldn't agree more. I call this ORYO: Only Repeat Yourself Once. Actually,
I often put comments in my code marking places I've already repeated myself
(saying 'ORYO' plus a reference, if needed).

------
admoin
Thoroughly enjoyed this post, especially since I remember a lot of these
events as they happened. I was peripherally involved in the startup also for a
good amount of time, and absolutely agree with everything he's said. I would
also add that a big reason we had trouble getting off the ground was that Jon
was really the only serious coder we had. The rest of us involved in the
startup had skills in other areas (marketing, graphic design, etc), which
although useful, were really NOT what the project needed at that point.

I would also say we probably fell in love a bit too much with our first idea,
and probably held onto it too long.

Oh, and think (1) low cost, (2) sustainable, and (3) ability to monetize. We
had #1 and #2 down pretty well, but had absolutely no real concept of how this
thing could possibly make money. Most startups are NOT going to get taken
over, so unless you are in it for non-$$$ reasons, it is probably a good idea
to at least come up with some way you can profit if you manage to attract an
audience but not a buyer.

------
tptacek
More posts like this, pls.

~~~
ucdaz
Shout out to HN and to the community!! This is awesome!! I'm always encouraged
and pumped learning from you all!! I don't think I would be following my
passion and dream of hacking a webapp without you guys!!! =) Nick

------
boucher
"I didn't realize how slowly I was working until I worked with a YCombinator
company. I was making about 6-8 commits/day; they setup a new Subversion
repository 2 days ago and it's already on revision 100."

Subversion commit rate is an abysmal measure of work speed.

~~~
nostrademons
They are, but nearly everything else is more abysmal. What else do you
measure, lines of code/day? Hours spent working? Bugs fixed? New files
created?

The nice thing about svn commits is that if you're doing atomic commits (and
both organizations were, though I got a little sloppy about it with GameClay),
1 commit ~= 1 feature. There're still issues about what you consider a feature
- if you do a feature right the first time and then check it in, is that
better than if you check in a barely-working rough cut, then a couple UI
enhancements, then some bugfixes for things you should've gotten right the
first time? But those issues would crop up no matter how you try to measure
forward progress.

~~~
boucher
I don't think there is one specific metric. It seems like SVN commits would be
more accurate than LOC, but when I hear numbers like that, I begin to
seriously doubt it. You have to take a lot of things into consideration when
trying to measure "forward progress".

In theory all of our commits are approximately one feature, and I can't, for
the life of me, imagine finishing 100 features in 2 days (even split between
all three of my team). Clearly there's some disconnect between what different
people consider to be a feature.

For the record, we've made a little over 1000 commits in the last five and a
half months. I certainly don't think that makes us 20 times less productive.

~~~
curiousgeorge
Good measure of how on-page the team is though.

It bothers me when developers aren't working on hard problems and fail to make
frequent commits. They are used to working in isolation and without scrutiny.
Unless people are actively breaking things they should be updating.

------
krschultz
Interesting, though I sure hope he is wrong about "If your idea starts with
"We're building a platform to..." and you don't have a billion dollars in
capital, find a new idea. Now.", since I work at a startup doing just that
(buglabs.net). We are selling though, so hopefully we are gaining some
traction.

~~~
ajross
Even a billion won't do. You can't write a "platform" from scratch. It just
doesn't work. All successful platforms (yes, every last one of them) started
out their life as useful tools with limited scope: the original Macintosh,
Unix, Java, Rails, even windows. All of these things started out as specific
products to fill a specific niche.

The only plausible counter-example I can think of off-hand is .NET. But even
there, it started out not as a new from-scratch platform, but basically as a
clone of Java with some windows-specific bits thrown in. So maybe a billion is
enough if you're just trying to compete, not innovate.

------
augustus
"The initial idea does change, and it's almost certainly wrong. The thing is,
the initial idea determines how the initial idea will change, which is crucial
to all the execution that follows it"

I completely agree with this. Paypal would not have got it right if they
didn't start with encryption technology or Microsoft with some kind of
software.

You may miss the exact product initially but it has to be the right direction.

------
maxklein
This is one of the better posts on this site. Long, insightful and
educational. I'm sure Tang will be successful in the future, as he comes
across and intelligent and humble.

~~~
nostrademons
Thanks. :-) There's actually a whole archive of posts (linked on the right)
that detail my thinking at various points in the venture; I haven't seen it
mentioned here, so I dunno if people don't know about it or haven't gotten
around to reading anything but the postmortem or just aren't interested. Some
of them may be helpful to folks though; there's a bunch on quitting the day
job from July 07 and a lot of Pylons/Django comparisons in Dec 07.

I'm going on vacation in about 10 minutes, so I'm not going to see the rest of
the discussion. If folks find other articles on the blog interesting, feel
free to submit them; I have more than enough karma already.

~~~
gscott
Seems like all of the work you did you might want to open source or look for
buyers for it. It seems like you made it pretty far.

------
DaniFong
Thank you for the post, Jonathan. It touched me. Enjoy your vacation, and I
wish you the best of luck towards your second act. :-)

------
edw519
Excellent post! One of the best ever. Very pg-esque.

It must take a lot of personal strength to put your failures out there for
others to learn from. Thank you.

 _It's very, very difficult to wear both the developer and the evangelist hats
at the same time: being a developer requires that you be very pessimistic, so
you can see and fix all the problems in your design, while being an evangelist
requires that you be very optimistic, so others can feed off your passion._

pg has mentioned many times that a startup is very difficult for a single
founder. If I remember correctly, he says that because it's too much work for
one person.

This is a slightly different angle that I had never really thought about. In
effect, you'd have to be "Sybil" with multiple personality disorder to pull it
off.

I tend to think of myself as a "very optimistic developer". I doubt I'd even
try what I'm doing if I wasn't. Does this mean I may miss major design defects
because of my rose colored glasses?

~~~
ojbyrne
This was the part of the article that resonated the most with me. I wonder if
this is the mechanism by which startups end up as big companies with totally
useless IT departments - the people who built the stuff become identified as
pessimists, and get starved for resources, good people leave, end up in a
vicious cycle.

Great post.

------
wallflower
FYI - Your blog made the SD Times News weekly email newsletter last week.

------
jrockway
From the article: _Linux started as a terminal emulator._

Huh?

~~~
mechanical_fish
<http://www.mach-linux.org/reviews/justforfun.html>

Even better, a video of Linus Torvalds speaking on the history of Linux at the
Computer Museum in 2001:

<http://youtube.com/watch?v=WVTWCPoUt8w>

------
louislouis
Thank you for the great article. One of the best in while.

------
zinxq
This seemed more like just a "website" than a start-up.

------
mercury
what was GameClay about?

~~~
blang
The history of the company is archived in the blog:

<http://diffle-history.blogspot.com/2007/02/intro-post.html>

