> One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when yo

> One of the biggest problems with TDD is that it kind of relies on having clearly defined specifications That's very true. I think it's an easier sell when you have a relatively stable set of specifications (accounting software core logic) where the rate of change is low but the cost of regressions is high. But I think you can tackle the same problem space with good unit tests instead of enforcing a test-first mindset. In situations where work is vague, spending more upfront time thinking about architecture is much more useful (design docs?) imo. Having a set of units for a crappy, entangled system is pretty costly.