This post originated from an RSS feed registered with Ruby Buzz by David Heinemeier Hansson. Original Post: The case against high-level components Feed Title: Loud Thinking Feed URL: http://feeds.feedburner.com/LoudThinking Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp Latest Ruby Buzz Posts Latest Ruby Buzz Posts by David Heinemeier Hansson Latest Posts From Loud Thinking

One of the clear goals for Rails from the start was to stay at the infrastructure layer. I didn't want Rails to succumb to the lure of high-level components like login systems, forums, content management, and the likes.

I worked in a J2EE shop for seven months that tried to pursue the component pipe dream for community tools with chats, user management, forums, calendars. The whole shebang. And I saw how poorly it adapted to different needs of the particular projects.

On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain.

So Dan Creswell's SOA doomed? rings particularly true in my ears. And reaffirms my belief that Rails will do the right thing by resisting the temptation of high-level components and focus on bettering the infrastructure:

All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality.

I have similar issues with the ever recurrent case tool dreams. I'll address those some time.