4 ms·

I agree with a lot of what you say. However, it takes a lot more time to write code guided by tests than it does to just write code. And you may end up throwin

I agree with a lot of what you say. However, it takes a lot more time to write code guided by tests than it does to just write code. And you may end up throwing away a lot of those tests and rewriting them when the code changes in response to customer feedback. In my mind that's the main argument against TDD. I'm happy to write tests after the v1.0 of an application is shipped and I have sign-off from my customer, because it is clear then that the time is not wasted - they have the working product as soon as possible, after all. However, in my world it's inevitable that I'll be assigned to another task almost immediately after I ship a product. Those tests often don't get written. I suppose I'm accumulating a lot of technical debt, but everything seems to work...

21echoes 15y ago
i feel the exact opposite-- if you have a good test, the code is nearly trivial to write. the key is to always bounce back and forth between tests and code, so that you're always just writing the minimum possible thing that passes, which (when looking at a test) is super simple. "throwing away tests due to customer feedback" is a red herring-- if you weren't throwing away tests, you'd be throwing away code. additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change. you should be sure that you're not going to drop this thing you're writing, because you've done the necessary user research to be sure the feature is needed and usable. "I'm happy to write tests after the v1.0 of an application is shipped and I have sign-off from my customer". if you're shipping untested code, that's a huge problem. the last thing you want is to deal with scaled feedback from a 1.0 release alongside ironing out code quality and reliability with tests
- arctangent 15y ago
  > the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change If only this goal were achievable! Unfortunately it is a frequent requirement of my job to show early prototypes and create new iterations of those products based on the feedback I receive.
- petercooper 15y ago
  additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change. To a point. But as a general rule, I don't agree. The goal should be to write code that's both loosely coupled and highly cohesive enough that you can defer as many changes or decisions as possible to the latest point possible. While this might involve spending more time in planning, the process of developing will itself impact the overall design (in most, but not all, cases).

21echoes 15y ago

i feel the exact opposite-- if you have a good test, the code is nearly trivial to write. the key is to always bounce back and forth between tests and code, so that you're always just writing the minimum possible thing that passes, which (when looking at a test) is super simple. "throwing away tests due to customer feedback" is a red herring-- if you weren't throwing away tests, you'd be throwing away code. additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change. you should be sure that you're not going to drop this thing you're writing, because you've done the necessary user research to be sure the feature is needed and usable. "I'm happy to write tests after the v1.0 of an application is shipped and I have sign-off from my customer". if you're shipping untested code, that's a huge problem. the last thing you want is to deal with scaled feedback from a 1.0 release alongside ironing out code quality and reliability with tests

arctangent 15y ago
> the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change If only this goal were achievable! Unfortunately it is a frequent requirement of my job to show early prototypes and create new iterations of those products based on the feedback I receive.
petercooper 15y ago
additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change. To a point. But as a general rule, I don't agree. The goal should be to write code that's both loosely coupled and highly cohesive enough that you can defer as many changes or decisions as possible to the latest point possible. While this might involve spending more time in planning, the process of developing will itself impact the overall design (in most, but not all, cases).