
Ask HN: Can a startup succeed with terrible code? - hackerbabz
I am the 10th employee and 3rd fulltime software developer at a startup which has so far seen some success. We have regular revenue from around 10 customers (a few of whom are fortune whatever-hundred), we have just gotten a small grant from the state we are located in and we are in talks with multiple VC funds, and have been attempting to push back our initial rounds because we believe our valuation is steadily increasing.  The other two devs have been here since the beginning, and I just joined in July. I have about 3 years of professional experience, and in my opinion, our codebase is garbage from top to bottom. Adding or fixing any feature is a monumental task requiring collaboration between all three of us, and there are sections I don&#x27;t bother touching without asking questions first. Furthermore, any request to refactor is mostly rebuffed by the fact that it doesn&#x27;t add immediate value to the users we are beholden to for our immediate survival. How common is this? Should I jump ship, or will any other startup be just as bad? Do successful startups have good code, or is it all just about the final result for users?<p>Tl;Dr Do most startups which get funded&#x2F;bought manage to produce good code, despite the pressure to produce features?
======
senko
It's all about the priorities.

For a startup that's still searching for the product-market fit, the code you
write today may have very short lifespan and the features you're building
today may end up being totally reworked (or thrown away!) next week.

The entire product is a throwaway Spike
([http://www.extremeprogramming.org/rules/spike.html](http://www.extremeprogramming.org/rules/spike.html)).
The code quality matters only as long as it works and can be used to test
whether the feature in question gets you more users.

So basically what you're doing is intentionally creating a mountain of
technical debt so that you can move super-fast, with the intention of only
paying it off after you know the code will be needed.

Once the product-market fit is achieved and the featureset stabilizes
somewhat, it makes sense to start cleaning up the codebase.

That's the benefit. The problem with this approach is that if the tech debt
catches up with you faster than you can figure out the product-market fit. In
this case it gets harder and harder to move and instead of going faster you go
slower, and it can kill you.

~~~
hex13
> Once the product-market fit is achieved (...)

> it makes sense to start cleaning up the codebase.

This is very optimistic assumption that people will actually clean the
codebase at some point. From what I've seen technical debt can stay very long
time. Temporary hacks can become permanent.

Spikes/prototyping can be quite effective, but to be effective in writing
spikes/prototypes a team must be disciplined to rewrite/refactor later. And
from my experience teams are often not very disciplined and pile of spaghetti
code begin to grow...

> The problem with this approach is that if the tech debt

> catches up with you faster than you can figure out the

> product-market fit. In this case it gets harder and harder

> to move and instead of going faster you go slower

Yeah. This is what I've seen. Even in startups quick and dirty code can be
developed over months. And in such long time pile of spaghetti just piles up
(people can make quite a mess in days. Imagine what they can do over
months...).

------
sidlls
It's all just about the final result. Doesn't matter if the back end is in PHP
or C or Go or Rust or Haskell or whatever. Doesn't matter whether one uses Qt,
React or pure JS or backbone or anything else in the client. What matters is
whether the customer gets the product they want.

That said, if you aren't happy there, look for someplace else!

~~~
hackerbabz
That's what I'm trying to understand. Do successful companies all have devs
working at 20% efficiency because of mistakes made in the past that there is
"no time" to fix? Am I just not cut out for this industry if I take pride in
my work and can't see myself writing shitty code forever?

~~~
sidlls
Not all companies are like that. Startups in today's Bay Area are
disproportionately likely to be.

Also, pride doesn't pay bills. That's definitely a consideration.

------
alexnewman
Normal from what I have seen

