
Ask HN: How many startups fail because of code base issues? - TheM00se
How many startups will fail as a result of having poorly written code and as a result it prevents them from growing when they need to pivot the most?
======
nostrademons
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.

~~~
TheM00se
Your reply really helped. I asked because Im in a position where the company
is 4 years old, they got initial traction. At this point they want to pivot
though, but the current code base does not allow for that because it cannot
support the new features.

~~~
angersock
How big a pivot are we talking? Totally different product?

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

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

