Define 'Failed'

1. TDD is Expensive

You need to test whether it is upfront or after! TDD allows you to fix bugs as they occur and not later when they are more difficult (ie expensive) to fix. Therefore, you should need less developers and take less time - TDD is cheaper!!! (If you do it right)

2. TDD Will Retard Your Project Launch

If you use TDD you will have production ready code very day that potentially can be released as an increment giving business value before the end of the 'project' - TDD can mean earlier business benefit

3. You Will Change Your Projects and Old Tests Become Waste

Projects don't change that much but products do. Yes all products change and some tests, whether they are written upfront or after will become old. Are you suggesting that we never write tests ie never do testing, because some will be seen as a waste later?


4. Testing the Means is a lot more Work Than Testing the Outcomes

To get the outcome right very bit of the means needs to be right.

Yeah - go ahead and just test the outcome and then try to find the problem that caused the outcome to break; takes a long time and is frustrating and expensive!


5. Extensive Testing is Boring

TDD can only work if you use automated tools which take the boredom out of extensive testing; if you don't use the TDD and CI tools then you will fail


Overall, I think that this list of reasons for TDD failure comes from people who don't understand the reasoning behind TDD; have speed read a book on it; never had an established practitioner coach them and don't really care about the bigger picture in their company.

Done properly, TDD is a game changer in most organisations.

Steve

Do you have your own company working on products for your business? If not, that explains why you seem to have difficulty to see the problems of TDD.

No - I am an Agile transformation coach and in every organisation of all sizes where I have introduced TDD there has been a rise in developer/management morale and customer satisfaction.

Maybe we do TDD differently!

I totally understand and agree that TDD increases self-confidence in the code you write and the morale of developers. However, it has consequences that more than often get in the way of succeeding with the projects.

But forget about my opinion, think about other people that are against TDD, for instance David Heinemeier Hansson of Basecamp, or Joel Spolsky and Jeff Atwook of Stackoverflow. They are partners of their own businesses. They build their own software projects.

They know there is no time to waste because there is competition and their is market opportunity. If you miss your opportunity and the competitor takes over your market because you have been distracted with TDD and other delaying practices, there is no developer self-confidence that compensate the failure of your business.

And if you ship a product that has not been properly tested, then you are more likely to lose customers.

I have looked at some of the products you mention and would never recommend them!

That's why the "Beta" stage exists!... you launch thinks that may fail, but does not care, you get feedback, correct the error and deploy, and again, like Gmail...

I am afraid you are still missing the point. You can properly test with doing TDD, test first.

Sorry, I meant "You can properly test WITHOUT doing TDD, test first."