I don’t think that the DD necessarily means you have to automate anything, although it obviously helps in practice.

The point is more what Dan North calls ‘outside in’ development - you only bother writing code because you have a concrete example - expressed from a user / stakeholder point of view - that the current code doesn’t satisfy. Without such an example, you don’t touch the code.

I agree it’s not exactly revelatory to be giving equal focus to functional requirements as well as technical quality, but this is the first time I’ve seen a relatively painless way of expressing what the code should and does do in a way that programmers, stakeholders, and the build server can all understand.

Both of those to be “*DD” seem to imply that there is some form of automation too. For TDD we have NUnit and CCNet, for the other kind we have Selenium, Fitness (now knowing what Fitness is I don’t think I will bother), and others.

I find it really interesting that some are now including “”"”"”Functional Requirement”"”"”" Driven Development (BDD, “Story Driven Development”) as being part of TDD as in this book in progress: http://www.mockobjects.com/book/tdd-introduction.html

So is the Agile world gone mad and simply re-inventing the wheel ? That is there should be equal focus in technical requirements (code quality, low coupling, sometimes performance) and functional requirements from day one of any project.

Am I mad doctor ?