5 ms·

I'm getting a little sick of hearing the "X Driven Y" construct. What made Test Driven Development so powerful was how it creates a workflow that allows a devel

I'm getting a little sick of hearing the "X Driven Y" construct. What made Test Driven Development so powerful was how it creates a workflow that allows a developer to reduce cognitive load by moving across layers of abstraction intelligibly. 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. It's something that every single other X Driven Y idea I've seen has completely lacked. Yes it's nice for an organization to have purpose beyond profit. 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? Is there a way to iterate from a normal enterprise in the direction of purpose, or does the paradigm force you to just start a new startup? TDD wrapped answers to all the problems it solved into a neat little workflow. This does nothing of the sort. I'm going to start thinking of these the same way I think about mall Cajun food.

spraak 10y ago
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')

spraak 10y ago

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')