For a startup that's still searching for the product-market fit, the code you write today may have very short lifespan and the features you're building today may end up being totally reworked (or thrown away!) next week.
The entire product is a throwaway Spike (http://www.extremeprogramming.org/rules/spike.html). The code quality matters only as long as it works and can be used to test whether the feature in question gets you more users.
So basically what you're doing is intentionally creating a mountain of technical debt so that you can move super-fast, with the intention of only paying it off after you know the code will be needed.
Once the product-market fit is achieved and the featureset stabilizes somewhat, it makes sense to start cleaning up the codebase.
That's the benefit. The problem with this approach is that if the tech debt catches up with you faster than you can figure out the product-market fit. In this case it gets harder and harder to move and instead of going faster you go slower, and it can kill you.
> it makes sense to start cleaning up the codebase.
This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.
Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...
> The problem with this approach is that if the tech debt
> catches up with you faster than you can figure out the
> product-market fit. In this case it gets harder and harder
> to move and instead of going faster you go slower
Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).
For a startup that's still searching for the product-market fit, the code you write today may have very short lifespan and the features you're building today may end up being totally reworked (or thrown away!) next week.
The entire product is a throwaway Spike (http://www.extremeprogramming.org/rules/spike.html). The code quality matters only as long as it works and can be used to test whether the feature in question gets you more users.
So basically what you're doing is intentionally creating a mountain of technical debt so that you can move super-fast, with the intention of only paying it off after you know the code will be needed.
Once the product-market fit is achieved and the featureset stabilizes somewhat, it makes sense to start cleaning up the codebase.
That's the benefit. The problem with this approach is that if the tech debt catches up with you faster than you can figure out the product-market fit. In this case it gets harder and harder to move and instead of going faster you go slower, and it can kill you.