I find TDD antethetical to this... you really need to actually understand the problem space - that requires large scale experimentation, not the micro-structuring TDD preaches.

Unit test driven development is antithetical to this.

Integration test driven development is very amenable though.

The problem isn't so much TDD as the cloud of dogma surrounding unit tests from people like Uncle Bob.

> Maybe we should invent a paradigm and write a manifesto about it. We can call it... test-driven development.

Isn't test-driven development the opposite, though?

If the program is layered as layers A (main program), B (business logic), C (data objects) and D (persistent storage), TDD would have you first do the interface (and tests) for D before you do anything for C.

You only realise if D is missing something (or worse, has superfluous features) once you start doing C. Same when you get to B.

When going API first, you go top-down. You first figure out what the interface to the main program (A) should be, then you figure out what the interface to B should look like, etc.

I always have to program from both sides, and hopefully meet in the middle. You need your low level stuff before your high level stuff works. but you don't know what low level things you will need until you do the high level things.

My understanding is that TDD would start with the main program (A), testing functionality that is exposed to the final user. The later layers would only be written if and when they are required for the end-user functionality.

I think that User-Centered Design (UCD) would be a better term here for what this concept is trying to say. In modern design, we tell user stories that help guide development of interfaces, including APIs.