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…
Ask HN: How bad should the code be in a startup?
61–70 of 183 posts
Re: Ask HN: How bad should the code be in a startup?
#62Re: Ask HN: How bad should the code be in a startup?
#63I 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?
#64Never 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…
Re: Ask HN: How bad should the code be in a startup?
#65Re: Ask HN: How bad should the code be in a startup?
#66a) 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…
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?
#67Never 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…
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?
#68Never 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…
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?
#69Managing 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…
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.