Not quite, you are committing yourself to throwing away your MVP and rewriting once/if you find the fit. That might be a very good idea if your MVP is extremely simple and you expect it to either fail or succeed with minimal iterations.
> Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero
Excellent point, but you probably want to factor in opportunity costs as well. You do not want to take on so much debt that it becomes impossible to succeed.
As soon as you start to iterate on the idea then the maintainability of your codebase starts to matter because that determines how quickly you can iterate on new ideas.
You do not want to get stuck doing even a partial rewrite while your competitors keep iterating their original higher quality codebase.
The overhead that testing or even full TDD add is very minimal if you have experience, so that's a tradeoff that must be made carefully. If you are thinking about learning TDD or testing while doing your MVP then that's a different story.
This is the same question as "should I use version control for my MVP" isn't it? The level of complexity for an MVP where this becomes a bad idea is different but it's the same question.
I agree, the assertion that you shouldn't test is absurd. For example, TDD can save you time by catching bugs for you. When Iv'e worked on apps without tests, I have to test manually each time I make a build, which gets annoying. That's time I could spend coding. I think the solution is something in the middle ground. TDD can sometimes veer off into a time wasting effort for the sake of TDD. Just TDD the complex parts, or the ones that are likely to break. Also write the tests that are easy, or quick to write.
Not quite, you are committing yourself to throwing away your MVP and rewriting once/if you find the fit. That might be a very good idea if your MVP is extremely simple and you expect it to either fail or succeed with minimal iterations.
> Put differently, your technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero
Excellent point, but you probably want to factor in opportunity costs as well. You do not want to take on so much debt that it becomes impossible to succeed.
As soon as you start to iterate on the idea then the maintainability of your codebase starts to matter because that determines how quickly you can iterate on new ideas.
You do not want to get stuck doing even a partial rewrite while your competitors keep iterating their original higher quality codebase.
The overhead that testing or even full TDD add is very minimal if you have experience, so that's a tradeoff that must be made carefully. If you are thinking about learning TDD or testing while doing your MVP then that's a different story.
This is the same question as "should I use version control for my MVP" isn't it? The level of complexity for an MVP where this becomes a bad idea is different but it's the same question.