3 ms·
I'd say that technical debt is often the best kind of debt you can take on as a startup. Difficult to maintain code is not going to be the thing that puts you o
by skrebbel 9y ago
I'd say that technical debt is often the best kind of debt you can take on as a startup. Difficult to maintain code is not going to be the thing that puts you out of business. Usually that's making the wrong product or not being able to reach your market.
Compare that to the other kinds of debt (convertible, for instance). They cost a lot of time to obtain and, potentially, a lot of money in the long run if you do well.
Many of the most successful startups had (have?) shitty code. Of course there's great counterexamples (i.e. WhatsApp having a 5 person backend team when they were acquired), but as a programmer and founder I find that my urge to make shitty code and ship fast is waay smaller than my urge to make fantastic beautiful code.
Of course shipping fast does not imply writing crap code in general. At all. But sometimes it does, and when it does, I've learned that hard way that maybe it's better to choose the crap code.
- marcosdumay 9y agoHow often being unable to change your code is the cause of bad product-market fit? How does needing 40 people instead of 5 to run your infrastructure compares with the carry cost of monetary debt? If you were only arguing that the people around here probably needs to be more open to technical debt because we here are mostly perfectionists I would probably agree. But I don't think I can agree with most of what is your post.
- skrebbel 9y agoBy the time we can afford to pay 5(!), let alone 40 people to run our infrastructure, I don't think you can call us a startup anymore. This is my point exactly. Until you've found product market fit, the size of the infrastructure team "once you're big" should be the least of your concerns. Personally I don't understand how any tech company with a 5+ person infrastructure team can still be called a startup (unless the infrastructure is the product ofc, eg if you're a PaaS or something)