TDD is not software design

Nicholas Ocket that's an interesting way of looking at TDD. I will go a step further though. I believe that TDD is a programming methodology and not a design one. In my understanding design is done on paper, before any line of code comes out of our keyboards. TDD is program-oriented in that it needs to know the inputs and outputs of each call, API, functional, etc, in order for tests to be designed. Therefore is moves into the middle space after design and before implementation. Thoughts?

Interesting take! TDD is often seen as a design philosophy, but in reality, it's more about ensuring functionality rather than shaping the architecture. While it improves code reliability, it doesn’t necessarily drive software design decisions. Curious—how do you see teams balancing TDD with broader architectural concerns?

Not believing TDD helped software design was one of the main reasons I didn't embrace TDD quickly enough. It take me a long time of doubting myself before I was confident enough to trust good design would not just fall out of TDD, although both are very important. I wish I could have articulated it then as well as this article does.

I have a different point of view here, and probably is because when I think about design I'm thinking not in something that happens from time to time but a continuous thing. In this case, design is based on small decisions that you can take and change only if things remain working as they were before. Following this idea, TDD is a design tool apart from a lot of others things. https://www.youtube.com/live/7aEIIonw_dQ?si=825nKw91V_g-9NvK

Tell me that you don't have a clue about software design by telling me that TDD improves your design.