Diary of a Failed Startup

"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?

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.

There are probably exceptions to every single one of the observations I posted, but that one was the one that most stood out for me, both based on this startup and the last one I worked at. If I do a startup again, I'll definitely be waiting for an idea that's an app and not a platform.

Something to ask about your company: are you going out to find customers, or are they coming to you? If it's the latter, congratulations; you've succeeded where thousands of entrepreneurs have failed. But if you have to make lots of sales calls to close that one sale, it doesn't necessarily mean anything, even if you're profitable. Try enough prospects and one is bound to say yes, if only because they have money to burn and want to see if you can help them out. That was a lesson learned at my last employer, which was profitable before I joined but got no new business while I was there, because their revenue came from customers that didn't really use the product and just bought it because a couple million is a drop in the bucket when you manage a few billion in capital.

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.

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.