from Hacker News

Ask HN: How many startups fail because of code base issues?

by TheM00se on 5/8/15, 12:56 AM with 5 comments

• by nostrademons on 5/8/15, 1:18 AM

  This is a pretty complicated question, because once you already have traction, a poor-quality code base is not going to stop you from succeeding, it'll just mean that your engineers curse you out for making their lives difficult and occasionally your users curse you out for bugs or scalability problems. Much of Google's early code is a mess (strangely, its post-2007 code is much cleaner, and yet many people think its post-2007 products are lamer), and I've heard Twitter and Facebook both have steaming piles of shit for codebases, though perhaps they've recently been cleaned up.

  However, if you don't have traction, having poor-quality code can make it impossible to add the necessary features/bugfixes that get you there, and can make it impossible to attract and retain the engineers that can do that. I worked at a startup once that died from this; we had a product that our one salesperson had no trouble selling, a prototype that worked great at demos, but we couldn't make it robust enough to launch a v1.0 that we could in good conscience charge for before running out of funding.

  However, if you focus on writing good-quality code, you are not focusing on the product, which also will prevent you from adding the necessary features, polish, whatever that will get you to traction. I founded a startup once that quietly died from this; it had a pretty innovative architecture and a relatively clean codebase, but wasn't really useful for users because I spent too much time refactoring and not enough building & polishing.

  Basically, you have to realize that you're gambling. Your goal is to put a usable product on the market. Every bit of code you write gets you closer to this, but also increases the difficulty of writing further code. Every bit of time spent refactoring makes it easier to write further code, but is time not spent improving your product. If you spend too much time writing features and never clean up code, it becomes impossible to deliver further features. If you spend too much time refactoring and never deliver new features, you lose out on the market to other companies that were willing to play a bit more fast and loose. Wisdom is figuring out a balance between them.

• by angersock on 5/8/15, 1:52 AM

  The codebase itself isn't the problem, really.

  What happens is your engineering talent--if you have any to speak of--starts to get really pissed off that they've had to repeatedly cut corners and now are being expected to save the day. This causes lots of stress, and the more experienced the engineer the more likely they are to either ragequit or make large compensations demands. It's not that the cutting corners is what bothers them...it's that the other folks so badly misjudged the business that the cutting corners was ineffective.

  Alternately, a competitor is able to look at your product, build a better architecture, and just plain kick your ass because it's more extensible and they can ship faster. I don't have any good examples for this offhand.

  As nostrademons points out, though, you can get farther with a good sales team and a shit codebase than with no sales and a great codebase. Lots of examples of that (including my previous startup).

• by MichaelCrawford on 5/8/15, 2:36 AM

  I can't really say but it's my impression that the problem is marketing rather than engineering. I'm thinking specifically of Live Picture, which didn't know how to price its product, nor how to compete with its direct competitor Adobe.