I think one important thing to keep in mind is that TDD is not necessarily synonymous with "software quality". In some cases it's a very useful tool to ensure t

I think one important thing to keep in mind is that TDD is not necessarily synonymous with "software quality". In some cases it's a very useful tool to ensure the quality of your code, but it's not even the stated goal of TDD, and a focus on TDD as the "one true path" to software quality ignores that some things are more effective (not necessarily simpler) to test using more of a "test later", integration-focused testing approach. I agree that there's projects where a simplistic MVC approach doesn't completely fit. That doesn't mean that every software project needs to be built to the standards of the most complex software, or even that aspects of a project that do require this complexity can't be solved with a more straightforward, simple MVC approach. At the end of the day, I think the main message I get from DHH's recent series of blog posts is that treating anything as a silver bullet, or a universally beneficial pattern is harmful - and this is equally as applicable to MVC for everything itself as it is for a complex, hexagonal architecture.