I think you have an opportunity to reframe TDD in your last sentence. TDD, like Agile and Scrum, is not a one size fits all solution. These are tools with pro

I think you have an opportunity to reframe TDD in your last sentence. TDD, like Agile and Scrum, is not a one size fits all solution. These are tools with process that have to be adapted to the people and the organization. That’s why the creators of these practices are declaring them “dead”, because people are blindly believing they are written in stone rules and that misses the intention. We made these rules to help ourselves and our organizations... not to overly constrain ourselves... add more discipline but leave room for flexibility that our jobs demand of us. Have you ever had to write some calling code, to call some other code, to make sure it worked? Don’t call it a formal test, I mean, a chunk of code that calls your other code, and you verify that the expected output is what you thought it would be? Coding is often a process of discovery. Architecture can be learned but applying it takes discovery and iteration. “Why do I need a certain architecture?”. Well, if you don’t know, code long enough, and do enough projects, and you might start discovering architecture all on your own. Then you might see how what you discover aligns with what others have discovered. Writing code can help you discover the right architecture, as long as you keep trying and keep iterating. Many of us had to learn and discover everything on the job, because not everything was known - much of it was being invented and discovered while we coded. Is that as efficient as learning known patterns and applying them? Maybe not, but also I believe the only way you can truly internalize the knowledge of a pattern or architecture is by implementing it, even when you don’t fully understand it. Therefore, you need to “test” it out to explore and discover it, to internalize it, to really learn and understand it. TDD in that respect can simply be seen as a helpful crutch to help you, as you explore, discover, iterate and learn. A “test”, whether it be a unit or integration test, is that chunk of code that calls some other code, so you can see if the other code works or not, especially in a mocked up context of how you think it should work later. TDD is just accepting at the beginning, “I only have a rough idea of what this should do, I’ll define a starting point to call into my code, even code I haven’t written yet, so I can explore and discover both that code’s external interface and also internal implementation, and see results sooner”. Using TDD is like sketching the blueprint of how you think the architecture should work, or how you want it to work, and then trying to color in the code in the middle, to see if it really does work. TDD isn’t an absolute. It’s just a helpful practice made by developers to try to help developers... and you will eventually do something like it, even if you don’t know what it is called... because that’s how we all code in the end. Think, code, discover, test, integrate... and iterate. TDD just suggests, start in a test, and then start thinking, and then continue as usual.. and let the testing framework help you assist you as you explore and learn.