Comment by grayhatter
2 years ago
maybe if you don't give a fuck about your users or the future maintainers, but for the time span of just 30m to make sure there's no bugs, and it's easy to maintain? MVP or not you're still a bad engineer if you actually do this.
Correct and broken are black and white if you can divide the problem correctly, and there's no excuse for shipping broken code. At some point someone has to take responsibility for not shipping garbage. I get that you, me, or any engineer don't always have that luxury, but it should be a shameful thing not something you accept as normal or ok.
Maybe spending 30 minutes on one bug is worth it, maybe not. If you're pre-revenue / pre-product-market-fit and you compound tens to hundreds of these 5s to 30m decisions, you're risking running out of time or money before anyone even uses your product.
I would argue it's much worse "engineering" to have no product at all.
> pre-product-market-fit
Is that a euphemism for wandering around aimlessly? committing random code to see what works? That's also not good engineering....
Not saying it won't end in the outcome you want people gamble all the time, I'm just saying it's bad engineering.
I mean, the default of any new company is pre-product-market-fit, no? How else could you start something new? During such an early stage much of your code may be written as a very rough MVP that you're only really using to validate a concept. Sometimes, you're going to just have to trash all of it because the idea was totally wrong and people don't actually care about the problem you're solving.
Those, among others, are the types of cases where spending extra time getting something exactly right (even if just a few hours) is just not worth it.
1 reply →