I just read Uncle Bob's Test Induced Design Damage?.

I keep fearing the day when Rails messes up and becomes too complicated or poorly maintained or something else, but that hasn't happened. It’s really an impressive solid project that solves common problems and steadily integrates popular solutions to new problems with each release.

However, Rails's design has some weaknesses that many agree on, and there is a healthy and vibrant discussion about developing new ways to build better software while still using Rails for its strengths.

I find it odd that DHH found it valuable to make such a strong stance against decoupling, and Jim Weirich’s talk in particular. I’m often a DHH apologist to some extent but now he just seems out of touch.

ActiveRecord models get too big when one tries to model large problem domains with them. The combining of business and persistence concerns starts to create obstacles and friction. Many smart people agree on this.

Controllers are difficult to test and reason about because, among other things, their input and output are the state of the system. Many smart people agree on this.

The larger Rails and Ruby community is making such great progress in developing new thinking and techniques for writing better software. I wonder what programming books DHH has read lately. It seems he sees the world solely through the lens of Basecamp.

What is most disappointing, and I think bodes poorly for Rails’s future, is that DHH makes no mention of where Rails needs to improve. Smart people throughout the community are complaining that Rails makes separation of concerns and testing difficult in large projects. His response is “please go back to how you were testing in 2008.”

To read about improving your software's design,I recommend the articles and books of Sandi Metz and Avdi Grimm.