I really don't think that TDD was the beginning of the 'X Driven Y' construct, though maybe you're not saying that directly here. > But how do you actually do

I really don't think that TDD was the beginning of the 'X Driven Y' construct, though maybe you're not saying that directly here. > But how do you actually do it? How do you solve the infinitely-many hard problems business throws at you and still retain your vaunted purpose? Sorry, but it sounds like you haven't experienced what it's like to be driven by a purpose. It works the same as you describe TDD, > Tests drive your development. At any point, you can simply run the tests and get an accurate picture of where the project is at. If it's all green, write more tests, if you have failing tests, fix the tests. only that trying to automated it would probably require some machine/deep learning, and so at this point the 'green' (and 'red') comes from your own internal/obvserved understanding of your direction and current state. TDD is rather just a part of what being 'Purpose Driven' means, for even with it, there is still a purpose (usually 'to have bug free, well working code and product')