Re:Ask HN: How bad should the code be in a startup?
by nmfisher on Sunday June 07, 2020 @09:07PM
(#23452580)
> In my case this was a relatively mature company on a version 2 reimplementation of an existing product, so it wasn't a complete death sentence.
OP specifically referred to startups, though, not mature companies. Most startups only have 12-24 months' runway to begin with, and lacking clean code/testing/best practices/etc won't (usually) kill them in that timeframe.
Lack of product-market fit, on the other hand, is the one thing guaranteed to kill a startup in that first year or two (lack of financing is the other, but this is usually fixable if you've addressed product-market fit).
It's why startups spend every single developer hour on rapid prototyping/iteration/features, rather than refactoring, testing and stability.
It's not black-and-white, though. Some code is so bad that it costs time in the very short-term, because noone can figure out how it works. Some functionality is so central to the product that tests are needed to confirm it's actually functioning as intended.
There's a vast spectrum between "fully tested, clean, reusable code" and "held together with sticky tape and segfaults every other minute".
I'd say that the one key skill for a startup CTO is deciding where the team should be on that spectrum on any given day.
OP specifically referred to startups, though, not mature companies. Most startups only have 12-24 months' runway to begin with, and lacking clean code/testing/best practices/etc won't (usually) kill them in that timeframe.
Lack of product-market fit, on the other hand, is the one thing guaranteed to kill a startup in that first year or two (lack of financing is the other, but this is usually fixable if you've addressed product-market fit). It's why startups spend every single developer hour on rapid prototyping/iteration/features, rather than refactoring, testing and stability.
It's not black-and-white, though. Some code is so bad that it costs time in the very short-term, because noone can figure out how it works. Some functionality is so central to the product that tests are needed to confirm it's actually functioning as intended.
There's a vast spectrum between "fully tested, clean, reusable code" and "held together with sticky tape and segfaults every other minute".
I'd say that the one key skill for a startup CTO is deciding where the team should be on that spectrum on any given day.