HN Explorer

Ask HN: Can a startup succeed with terrible code?

2 points by hackerbabz ↗ HN
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't bother touching without asking questions first. Furthermore, any request to refactor is mostly rebuffed by the fact that it doesn'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?

Tl;Dr Do most startups which get funded/bought manage to produce good code, despite the pressure to produce features?

7 comments

[ 2.9 ms ] story [ 20.1 ms ] thread
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?
[deleted]
(comment deleted)
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.

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