Live data from Hacker News

Ask HN: How bad should the code be in a startup?

news.ycombinator.com

61–70 of 183 posts

Re: Ask HN: How bad should the code be in a startup?

#61

Unless your startup is building some new tech product (like a new database technology, or a crypto/blockchain system) that is going to be sold to customers, software code quality doesn't matter much, at least initially for sure, and may be ever too. Most likely you are startup building a software application service that is augmenting or automating or orchestrating some real-world interaction (like an e-commerce shop…

It depends how bad it is. I inherited a codebase that had wildly inconsistent data in it's (schemaless) database, because there was no (or very little) input validation. When I joined, the dev team was spending 50% of their time fighting fires and dealing with bugs reported by customers. This was all justified by "move fast and break things", but the reality was that the code quality issues were massively slowing down feature development.

Re: Ask HN: How bad should the code be in a startup?

#63
A rule I use for testing: If a feature doesn't run correctly the first time it's manually tested, then an automated test should be created which checks if the feature is working. This rule typically means that tests save time, and that tests are created for the code that's likely to break.

I bypass this rule when I think it's obvious I'm going to want automated testing. For example, I needed a customer facing DSL for importing data with a lexer/parser/interpreter; manual testing was bypassed from the start.

Re: Ask HN: How bad should the code be in a startup?

#64

Never 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…

[deleted]

Re: Ask HN: How bad should the code be in a startup?

#66
post #17

a) has Hacker News/YC ever seen a startup fail because the codebase is so bad. Yes, I've been seen this happening on some projects that I joined. The most hilarious story I've is when a funded startup spent 12 months with a team of 5 and the app would crash with a single user with little usage. I managed to rewrite a functional prototype/v3 in 3 months that worked much better. Others were so costly to refactor and go…

Those last paragraphs hit the nail on the head.

Business often doesn’t seem to treat developers (or any workers) as a first class value. This is true in the small just as much in the large. Hence the grotesque term “Human Resources”.

Writing “clean” aka pragmatic, well abstracted, robust, performant and readable code becomes naturally less “expensive” if practiced regularly (who would have thought).

So it is also an investment in developers: their skill, communication, happiness and engagement.

Disregard of that is short sighted and cynical. Just paying someone (well) instead of investing in them and growing with them leads to unhappy, stressed, uncreative workers, erodes trust and limits engagement.

Re: Ask HN: How bad should the code be in a startup?

#67

Never 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?

Re: Ask HN: How bad should the code be in a startup?

#68

Never 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!). New developers try to pick it up, including a new hire, try to work with it. Warnings about runway loom. Support is swamped and many of the tickets get kicked up to developers because support can't answer because they're obscure bugs. Most of developers time is spent trying to fix the worst bugs, but things just get worse because each bug fix introduces new bugs, cause the code-base is well neigh incomprehensible. Some developers see the writing on the wall and flee, leaving even more work for the remaining developers. No money for new hires. 3 months later, layoffs. 1 month later, closed. One poor guy is laid off 4 months after being hired.

Lather rinse repeat.

The upshot is crap code makes a crap product. Just like crap engineering makes a crap car. Customer do care about that. They'll get tired of the bugs and the infrequent updates and the poor support and eventually they'll move on.

Re: Ask HN: How bad should the code be in a startup?

#69

Managing technical debt is always a trade off. The company I work at is failing at it. We: * Bootstrapped a startup, left ourselves tons of tech debt * Glommed as many features onto the core product as possible to meet enterprise needs * Got a ton of MRR and are the leader in our corner of the industry * Never pivoted to being a mature company, never paid off the debt. Now the bugs are pretty unmanageable and the sof…

About 50% of our customers try the software and churn out within six months. Our client industry is only so big, and we’re actively pissing off a huge chunk of it.

What that means is that you haven't yet found your product market fit. Better not scale up or you will burn.

Check "sell more faster" by Amos.

Post reply on HN