4 ms·

So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. As for throwing away tests;

So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. As for throwing away tests; Unit tests are meant to be pretty simple - rule of thumb is you can run a thousand tests in ten seconds. Arrange, Act, Assert - they don't need to be complex, they just need to imprint the intent into the codebase. If the intent changes, by all means remove the test.

nilkn 9y ago
> So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. Not necessarily. If the rewrite is only addressing issues that would have been prevented with tests, then sure, this is clearly an argument for TDD. However, if the rewrite is going beyond what could have been provided by tests, then having a large testing system could actually make the rewrites harder, which means it's an argument against TDD. It's hard to say which is the case without knowing the details, and I'd certainly err on the side of saying a yearly rewrite is not a good sign. But if a company is undergoing rapid growth, it's not that unusual for certain systems to be rewritten frequently as fundamental new insights are gathered about how to tackle problems that are hard to scale. And if the system isn't that large to begin with, periodic rewrites could be easier than writing a single version that's supposed to last 10+ years as business requirements dramatically change and expand.
- Fifer82 9y ago
  I agree. My experience is: 1. Wow it made 10k! Lets rewrite 2. Wow it made 100k! Lets rewrite 3. Wow it made 1M! Lets rewrite but let's properly think hard about the future of this product (Introduce tests and more people). ALWAYS DO TESTING should always be given the context (if budget allows).
ozim 9y ago
We rebuild because business needs change, because compliance and stuff. It is not like we rewrite because code is crap. We have like 30 percent of test coverage because that is part that changed only a bit.

nilkn 9y ago

> So you disagree with TDD, but you need to rebuild your system from scratch every 5 years? I feel like this is an argument for TDD. Not necessarily. If the rewrite is only addressing issues that would have been prevented with tests, then sure, this is clearly an argument for TDD. However, if the rewrite is going beyond what could have been provided by tests, then having a large testing system could actually make the rewrites harder, which means it's an argument against TDD. It's hard to say which is the case without knowing the details, and I'd certainly err on the side of saying a yearly rewrite is not a good sign. But if a company is undergoing rapid growth, it's not that unusual for certain systems to be rewritten frequently as fundamental new insights are gathered about how to tackle problems that are hard to scale. And if the system isn't that large to begin with, periodic rewrites could be easier than writing a single version that's supposed to last 10+ years as business requirements dramatically change and expand.

Fifer82 9y ago
I agree. My experience is: 1. Wow it made 10k! Lets rewrite 2. Wow it made 100k! Lets rewrite 3. Wow it made 1M! Lets rewrite but let's properly think hard about the future of this product (Introduce tests and more people). ALWAYS DO TESTING should always be given the context (if budget allows).

ozim 9y ago

We rebuild because business needs change, because compliance and stuff. It is not like we rewrite because code is crap. We have like 30 percent of test coverage because that is part that changed only a bit.