I think there is actually a meaningful distinction between the two. "Specification Driven Development" refers to the artifact you are creating; whereas "Test Driven Development" refers to the activity you are using that specification for. You are right that in the case of TDD as typically practiced, it doesn't really matter since the specifications are only used to conduct tests. However, if you treat the specifications as _data_ rather than code, you greatly increase kinds of verification activities you can with those specifications; such as theorem proving, model checking, test generation, code contracts, and documentation. See the talk "Beyond Contracts: An Exploration into Unified Specifications" -- (http://www.infoq.com/presentations/Unified-Specifications-Cl...) for more on this idea.

Yeah, but using the right terminology makes the concept more self-describing and therefore more accessible.

I was around when the term TDD first appeared. And I don't think that originally it meant anything more than what you are proposing.

But then some dudes came along and said: "This is awesome, lets make it better!"

And before one could blink, a concept of 100% coverage was born. From there on everything went full retard.

I completely agree that TDD originally meant that, and still does. The problem is too many developers don't bother to learn what TDD really means and immediately think of it as a testing methodology because the first word is "test". Maybe changing the language can change the focus to where it was supposed to be from the beginning.