Let me give you the punchline and then explain myself:

As soon as testing starts every “project” becomes a test driven.

If there is no formal testing period then that phase began the moment customers/users started using the product.

I’ve recently been watching a slow motion train crash, I had no power to stop it and those I could alert didn’t want to hear me. So I was thinking: what will happen in the end?

The project has been forced on the organization by external authorities. Even if it wasn’t the budget allocated means, it is too big to fail, it will take careers with it so it must succeed. It will be an exercise in pass the parcel with everyone attempting to show they did what was expected to avoid blame.

Anyway, in the end, I thought, they will enter a testing phase, as with all testing phases it won’t be just a test phase it will be a test-fix-test-fix until such time as the organization runs out of the will to continue. Just like every traditional project.

Which, when you think about it, means that when this project enters testing it will become Test Driven.

Sure the project will spend months “designing” and “implementing” but the project is so big nobody can understand it. Only when the parts are brought together, and the deadline is close, will people do what is required.

At that point, they will be test driven.

Up until that point all the planning, designing, implementing, and what not is just shadow play, people avoiding doing what is needed.

This argument can be extended to every traditional project where testing is left to the end.

Between the start of work and the start of testing, work might be done, but how much of this is usable, and how much is included in the final solution is anyone's guess. Once you begin testing, all work is test driven.

All software development is test driven, in the end.