Great article! Just a few remarks: The the Helsinki data in the visualization bother me. (I know you’re just quoting there, it’s not your fault.) They show a small gain in maintainability, but a big loss in productivity. I think this is very misleading. Products with a long lifecycle have a blurry, drawn-out transition from creation to expansion to maintenance. And all projects I ever worked on had — or would have had — huge benefits from a clean architecture. Now what has this to do with TDD? Well, one of the key factors of a good architecture is loose coupling, typically realized by dependency injection kung-fu. TDD forces you to do that from the start. (Conversely, if you conclude that TDD is cumbersome, you typically lack dependency-injection skills.) And indeed, I’ve observed a close correlation between loosely coupled architectures and a genuine TDD culture. When someone tells me their team goes easy on the unit test, I can almost guarantee that, on looking into their code, I’ll find unmaintainable tight coupling that will bog down the project in the long run.