Thomas Roch

1. #TDD requires refactoring continuously with no visible end in sight for when that will stop. So each iteration, a developer makes a solution with quality oversight at a minimum knowing in the back of their head that they will have that code rewritten. This is a major issue that makes code reviews a nightmare in the process. You're always reviewing a half-assed implementation tied to how complete the requirements are. 2. If one designs up front (eg with @EventModeling) the design part of TDD is not needed. So refactoring over and over again isn't necessary. Note that, test first/last and unit tests alone are not TDD. More importantly, the design is not siloed to just developers if you design collaboratively with other roles. 3. Making TDD unit tests a form of documentation silos that to just developers. 4. TDD pair programming, ping pong test- implementation rotation, mobbing are more examples at siloing system design to just developers. I'm not even including the over reliance on the right social conditions to have that (especially with introvert devs) as an option when designed systems don't need any, relatively speaking. 5. The amount of code in scope for refactoring grows with the size of the feature as you add more tests for the implementation of the feature. Macro refactoring that coders love tweaking extend this code massaging to the entire solution. The only way this works is if you've defined a perfect unit to keep scope in check. But that's a catch-22 because the perfect design is the outcome of the TDD cycle itself. This means refactoring is a free-for-all for most. 6. TDD aims to have "the best minimal design and implementation and working code" at the completion of each cycle. This a complete waste of effort. The differences at each addition of functionality is not trivial to reach those guarantees. So the best abstraction rarely happens and at any point the released software is at a sub optional design under the excuse that "software is never finished" anyway. 7. A design with granular modularity as you get with #EventSourcing allows for replacement of entire steps. This is what gives proper units that I mentioned before. But they are small enough that instead of maintaining them, you can wholesale replace them. There is little to no value for TDD here. 8. TDD assumes we will not have any commodity to the steps used to put together workflows. So everything must be designed like a brand new bespoke solution. Don't even think about copying how a previous step worked when you're implementing yours. This is commonly done in #EventSourcing and I'm sure other methodologies give similar building blocks. Add to this #AI where you actually want boring code to train the model more reliably instead of from subjective hot takes on design of each skill level of developer in you org. 9. TDD was sold as a better than the worst thing in the industry. But in reality, almost anything would have been better than the 2 year BDUF from the 80s and 90s. The right question was "How do we improve design" instead of "How do we replace design". These days it's just tilting at windmills. The agilists outright ousted design. They made it a detail in the hands of just developers in the worst time in the SDLC. This sold well to both sides "wow, we the developers finally have a say" and the overseers "wow, we don't have to worry about this now, the devs will take care of it plus we can pit them against one another in a constant high stress scrum for efficiency's sake". After 2 decades of doing TDD and BDD, I've realized that ignoring design and thinking that TDD will do a decent job at it for a trade-off for quicker/higher-quality development with the extra time was entirely a scam. I've covered two aspects here: A) why TDD is bad for any development given higher costs and lower quality growth with size of solution, and B) how superfluous it is when you have granular modular design provided outside of it.