Successful startup code quality is on par with HR quality and Legal quality. Far below Marketing quality.
Ask HN: How bad should the code be in a startup?
121–130 of 183 posts
Re: Ask HN: How bad should the code be in a startup?
#122In my experience, "code quality" vs "features" is simply not a real tradeoff. Writing clean code with tests, function documentation, a good level of modularity, automated deployments... etc will save you time in the short term . It's pretty simple: 1. Writing quality code is not substantially slower in the first place, especially when you factor in debugging time. You just have to have the right habits from the get-g…
As a technical cofounder who just finished the YC W20 batch ( https://terusama.com ), I can agree with some of what you are saying. At its core, an early stage startup's only goal is to create business value as ruthlessly as possible. Let's talk about how I apply this principle to my testing strategy. Do automated test suites help create business value? Absolutely, I no longer have to test everything after making a c…
I think I disagree with this. I think the short-term harm of this kind of tech debt is more substantial than you're leading on. "Causing myself problems for the future" might be true, but that future could be in a week when you need to pivot because of user testing, a shift in the market, product market fit etc.
I think the mistake you're making is conflating "getting code written now" with expediency. Adding/removing features and shifting when necessary are "expediency." That's the value of a thorough test suite.
Re: Ask HN: How bad should the code be in a startup?
#1231. Launch product, make money.
2. Fix up your code.
Re: Ask HN: How bad should the code be in a startup?
#124Earlier quoted context omitted.
As a technical cofounder who just finished the YC W20 batch ( https://terusama.com ), I can agree with some of what you are saying. At its core, an early stage startup's only goal is to create business value as ruthlessly as possible. Let's talk about how I apply this principle to my testing strategy. Do automated test suites help create business value? Absolutely, I no longer have to test everything after making a c…
I think I disagree with this. I think the short-term harm of this kind of tech debt is more substantial than you're leading on. "Causing myself problems for the future" might be true, but that future could be in a week when you need to pivot because of user testing, a shift in the market, product market fit etc. I think the mistake you're making is conflating "getting code written now" with expediency. Adding/removin…
It's not just the test suite that is the subject of tradeoffs. One may write good code that fundamentally doesn't scale beyond a small number of customers e.g. doing everything with postgres and no batching because it's easy. Or building a solution for a demo to an individual customer.
These solutions will break, and if monitoring is skipped will break at 2 AM when customers really start using the product.
These situations can be avoided with better product research and a stronger emphasis on design, but these are also the approaches large established companies take who can't afford to lose customer trust, and will gladly build a product on a 2 year time horizon.
As a startup you need to weigh the risk of failure, the need for direct customer engagement, and limited resources against the risk of losing customer trust. If you're a startup making a new DB, then you're product lifespan is approximately equal to the time until your first high level customer failure or poor jepsen test. A new consumer startup, may simply be able to patch scaling issues as they emerge rather than investing in a billion user infra from the get go.
Re: Ask HN: How bad should the code be in a startup?
#125Friendster was one of the first social networks, way ahead of Facebook.
My understanding is that a major reason they failed was poor code and an inability to maintain performance.
Re: Ask HN: How bad should the code be in a startup?
#126Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Could they fail because they fail to meet deadlines due to convoluted or buggy code or having to invest more money and time to fix those issues and bugs introduced by them?
[deleted]
Re: Ask HN: How bad should the code be in a startup?
#127Earlier quoted context omitted.
Special case of 1: security bugs. If your app's audience is BLM protestors and it leaks their personal information somewhere, it would be better (both for the world in a moral sense and for your business in a pecuniary sense) not to release it at all until it doesn't.
Ideally an app targeting protesters wouldn't collect personal information to begin with.
There's a lot of ways it could do so unintentionally - for instance, if it captures photos, it needs to scrub metadata like geolocation and it needs to allow you to black out portions of the photos before uploading them. But yes.
Re: Ask HN: How bad should the code be in a startup?
#128Great qs!
a) A really bad codebase like the one you're describing hasn't been the root cause of any failure that I've seen, and I have seen several companies recover from it and become very successful. Unfortunately what you're describing may be a symptom of a different root cause (poor judgment around what matters most to the business), and that can def kill you.
b) These things don't trade off against one another directly. Code quality helps feature velocity. In the early days the only thing that matters is getting product/market fit as that's an event horizon beyond which the future is unknowable; the way to get there is to iterate fast, which does require things like CI/CD and a coherent/non-spaghetti structure (even if the code itself is ugly).
c) I've seen both modes. My main view: what matters most pre-product/market fit is rapid iteration (see above). Once p/m fit has been achieved you need to be able to add features rapidly, which requires a different level of code quality (comprehensive tests, etc). There's no hard and fast rule here, but most products ultimately throw away most of their pre-product/market fit code within 1-2 years of scaling.
I actually recently wrote a blog post that touches on a lot of this here: https://staysaasy.com/engineering/2020/05/25/engineering-at-...
Good luck with whatever you're up to, whether at this company or elsewhere!
Re: Ask HN: How bad should the code be in a startup?
#129Never forget that your startup customers aren't buying your code. They're paying for whatever the product does for them. They don't care if the code is good or bad, as long as the app does what they need it to do and does it well. So to answer your question: The code should be bad enough that it allows you to ship as fast as possible, but not so bad that the app doesn't work properly. This can be a shock if you've be…
> However, startups don't fail because the codebase is ugly, or convoluted, or not following best practices. Could they fail because they fail to meet deadlines due to convoluted or buggy code or having to invest more money and time to fix those issues and bugs introduced by them?
Yes, totally.
They could also fail because code/architecure is overengineered, not invented here syndrome or because of premature optimization.
In the beginning, being able to adopt and/or pivot quickly might be much more important than to have 100% test coverage, keeping up with the latest JS framework or being able to scale to 100M users.
Re: Ask HN: How bad should the code be in a startup?
#130[deleted]