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

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