3 ms·

This works provided you didnt encode your design mistakes in the tests themselves. Then youve just doubled the cost of fixing that mistake. It's hard to overst

by pydry 5y ago

This works provided you didnt encode your design mistakes in the tests themselves. Then youve just doubled the cost of fixing that mistake. It's hard to overstate how common this is.

Jtsummers 5y ago
> This works provided you didnt encode your design mistakes in the tests themselves. Then youve just doubled the cost of fixing that mistake. 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? In extreme cases, but in others you do partial rewrites and refactors. Address the issues. But not having tests because they may encode your design mistakes is as foolish as not having documentation or comments because they may also encode your design mistakes. 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. And so what if it doubles the cost of fixing the mistake? You made a mistake and it had to be fixed anyways. In the end, I've never found tests to cost more than they saved. A lack of tests has always led to higher development costs (primarily as measured in time to delivery). Regressions are ludicrously common without tests, which eats away at your time (and therefore adds to your costs) very quickly.
- pydry 5y ago
  >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.
MrMan 5y ago
yes design mistakes cost much more to a project than broken implementation in my experience. broken code is harmless compared to a codebase that has to be rewritten after the true requirements finally reveal themselves

by pydry 5y ago

This works provided you didnt encode your design mistakes in the tests themselves. Then youve just doubled the cost of fixing that mistake. It's hard to overstate how common this is.

Jtsummers 5y ago

> This works provided you didnt encode your design mistakes in the tests themselves. Then youve just doubled the cost of fixing that mistake. 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? In extreme cases, but in others you do partial rewrites and refactors. Address the issues. But not having tests because they may encode your design mistakes is as foolish as not having documentation or comments because they may also encode your design mistakes. 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. And so what if it doubles the cost of fixing the mistake? You made a mistake and it had to be fixed anyways. In the end, I've never found tests to cost more than they saved. A lack of tests has always led to higher development costs (primarily as measured in time to delivery). Regressions are ludicrously common without tests, which eats away at your time (and therefore adds to your costs) very quickly.

pydry 5y ago
>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.

MrMan 5y ago

yes design mistakes cost much more to a project than broken implementation in my experience. broken code is harmless compared to a codebase that has to be rewritten after the true requirements finally reveal themselves