>If your design mistakes are in your code and your tests, they'll also likely be in your mental model and your documentation (if it exists). At which point you

>If your design mistakes are in your code and your tests, they'll also likely be in your mental model and your documentation (if it exists). At which point you what? Throw it all away and start over? Kinda, yeah. Or huge chunks of it. Thats what the OP said. I've done a lot of that. Was that a rhetorical question? >And so what if it doubles the cost of fixing the mistake? You made a mistake and it had to be fixed anyways. Well, then assuming you need 1 month to do a product iteration and 1 to do tests and docs on it and you need 5 iterations before landing on the "right" requirements to meet product-market fit, that requires 10 months to get to fully tested code doing the right thing with TDD and 6 without. What if your runway is 8? >In a few years, you'll have a blob of code that, in the best case, is perfectly readable and comprehensible. But, in reality, is likely to fail at communicating the overall design intent and requirements. I've been on both sides of this problem and I honestly think that this is much less dangerous than not iterating on requirements fast enough. I've bailed a company out of a massive technical debt hangover before. It's horrendous but it's not usually fatal. But solving the wrong problem? Not finding the right problem soon enough? That's usually fatal.