My advice is to not worry too much, but to follow the boy scout rule: leave code in slightly better shape than you found it. Code quality matters to no one - not even other developers - if the code in question is never revisited. The boy scout rule helps ensure that code that doesn't need to be good doesn't have time wasted on making it better, and code that needs to be higher quality naturally becomes higher quality.
Ask HN: How bad should the code be in a startup?
81–90 of 183 posts
Re: Ask HN: How bad should the code be in a startup?
#82Startup code needs to eventually scale and it needs to be flexible. I have no problem with "crap" code as long as it makes sense in the context and works. In a lot of cases, it would be extremely counterproductive to write "perfect" code that then needed to be thrown away a few months later when your product changes.
Re: Ask HN: How bad should the code be in a startup?
#83In 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-go. People avoid writing quality code because they don't have and don't want to build these habits, not because it's inherently harder.
2. After the initial push, code quality makes it much easier to make broad changes, try new things and add quick features. This is exactly what you need when iterating on a product! Without it, you'll be wasting time dealing with production issues and bugs.
The only reason people say startups don't fail because of code quality is that code quality is never the proximate cause—you run out of funding because you couldn't find product-market fit. But would you have found product-market fit if you had been able to iterate faster, try more ideas out and didn't spend 50% of your time fighting fires? Almost definitely.
Pulling all-nighters dealing with production issues, spending weeks quashing bugs in a new feature and duct-taping hacks with more hacks is not heroic, it's self-sabotaging. Writing good code makes your own life easier, even on startup timeframes. (Hell, it makes your life easier even on hackathon timeframes!)
Re: Ask HN: How bad should the code be in a startup?
#84Earlier quoted context omitted.
Security as in being able to login with any JWT you cared to create... just change the email address to anyone using the app and you’re them, no signature checked whatsoever :-/
Are you referring to something specific that I'm not aware of? :)
All I’m saying is there are levels of bad... I suppose this is covered by your comment! But seriously :-)
Re: Ask HN: How bad should the code be in a startup?
#85Earlier quoted context omitted.
> a) Almost every startup I know of that failed, failed because of business reasons, not tech. Even when it was tech, the reasons were delays in feature delivery and production issues, not code maintainability or tech debt. Some companies paid dearly later on to fix tech debt, but if they hadn't moved fast in the first place, they wouldn't have had customers to lose. Delays in feature delivery and production issues a…
I know I might be in the minority here, but tech problems that are already affecting users (even indirectly in the form of missing features), I tend to consider as more than tech debt. The payment has already come due. If there are real world impact beyond just standards & best practice compliance, we have to fix right away.
[deleted]
Re: Ask HN: How bad should the code be in a startup?
#86My advice is to not worry too much, but to follow the boy scout rule: leave code in slightly better shape than you found it. Code quality matters to no one - not even other developers - if the code in question is never revisited. The boy scout rule helps ensure that code that doesn't need to be good doesn't have time wasted on making it better, and code that needs to be higher quality naturally becomes higher quality…
This is fine advice, but it's really advice for an individual more than an org, and if you are in leadership you need to consider whether your teams and processes are set up in a way that both leaves room for your engineers to do this and also ideally even actively encourages their doing so.
To phrase it another way: Each engineer might have the best of intentions but if success is measured by new feature velocity, adherence to this rule becomes less likely.
Re: Ask HN: How bad should the code be in a startup?
#87if you're doing your job as a startup coder you shouldn't have to balance btwn insecurity bugs + spaghetti
that's a false choice. in reality you can have all three
'get things done pretty fast' is the only red flag in your story -- if you want your life to be truly worthwhile you must make this codebase unproductive as well
Re: Ask HN: How bad should the code be in a startup?
#88Never 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." Yes, they do. The obvious one is one senior developer who writes a bunch of trash code to get stuff done in a hurry. Later is asked to maintain it and add features. But it's no fun cause it's a pile of poo. New shiny attracts his attention and he moves on (cause, you know, he delivered at his current job!). Ne…
I've never worked on a project o bad I could add features fix bugs to it.
And I worked on a project that literally saved the HTML on the page into a varchar, had 15,000 lines of JavaScript, and all the business logic was written in awful stored procedures.
Whatever speed quality trade-offs a good engineer is making will be worth it when a startup is still in the "I don't know if this company will exist in 6 months" phase.
Re: Ask HN: How bad should the code be in a startup?
#89Until product/market fit only care about your code quality enough to not make your best engineers quit.
Post product/market fit, care about it deeply and enforce strictly.
Re: Ask HN: How bad should the code be in a startup?
#90Writing a service thinking that you'll throw everything away is a waste of time. And so is trying to get everything perfect, because you don't yet understand the business correctly.
In my experience you should not treat all parts alike, the more foundational the more time you should dedicate.
It's important to think the db schema properly, anything else will cripple your development, and the longer in the run the harder it will be to fix it. You don't want to sanitize wrong data two years into business.
If there's a library, it's better to spend time on thinking the proper API, the code can be later be improved.
It's ok to have garbage as long as it can be isolated and you can keep on going. For example, we had configuration files that had to be synced with the db. That could have been automated, but it was ok to hardcode them in config files. It was not ok to hardcode them across the whole code. First one could be turned clean in the future, second one would've been a mess.
Invest in tests, specially setting up the process. At the beginning they can be just smoke tests (this API returns success), as the start up grows you'll have more options to add proper tests.