Convention vs. Configuration – original post 2006.09.05

Unless you’ve stayed removed from the open Internet and general development news the past year, you’ve been inundated with articles about Ruby on Rails. There has been an immense level of hype, and more recently, established systems and frameworks have been almost counterattacking for lack of a better word against Rails.

Much like the polarized debates I attended at the DDJ Architecture and Design World conference in Chicago a few months ago, the screaming is always about volume, not content. At the conference, those who believe Model Driven Architectures and such are dead-end academic nonsense shout louder each year with more invective and never engaging in meaningful explorations. It’s not that they don’t believe any of the ideas, in fact, some are on both sides of the debate quite deeply, but the public discussions too often degenerate into a shouting match of x vs. y.

With Rails, it gives another view of the increase in capability of a developer, much like MDA allows in some scenarios. It’s no panacea, and like MDA, Rails has it’s solid successes, it’s marginal areas, and areas where it just isn’t up to the task compared to other frameworks today.

The point is the core idea that you will come across in article after article and book after book on Rails. Convention over Configuration. In ASP.NET and Java web applications, you have quite a serious amount of configuration in the development of the application. Some of the IDEs automate portions of this, but in every case, the power of the environment hits you square in the head when you’re using it, even when you don’t need the power. That’s where Rails changes the model, and finally, some of the Java frameworks (and possibly others) are taking notice. They give intelligent, most-often-used cases as defaults. Conventions of capability and use rather than an open box of parts. You can still, sometimes with a great deal of effort mind you, change that aspect and configure things specifically to your needs. That’s the right thing. But needing a simple CRUD web app for a database, you should not need to configure the three tiers, and distributed transactions and processing systems for a 3 day project.

I made the case that it is precisely because we are still writing in C# and Java and these decidedly C-like languages that so much work IS getting outsourced, and why we as IT professionals continue to fail in satisfying our users. We are using tools and languages that represent the same incremental abstraction from the processor that C and Fortran did in the 60’s. Our representations of components, modules, concepts and constructs are still linked directly to the idea of index variable loops and branching constructs of comparisons. It’s not that we need to do away with those. Some of the decision and looping logic is fundamental to software development. The point is we are continuously trying to achieve more sophisticated systems, richer interaction models and more scalable and distributed systems with the same tools we were writing command line utilities and our first compilers with. Seems rather inefficient. I regard it as a unique failing of our profession to date, and it’s why I will continue to explore technologies like Rails, like Ruby and MDA, and even go back to examine the more powerful technologies of LISP and other conceptual languages to find a way to get out of the rut we are trapped in.

It’s not about which framework is “best”. It’s about taking ideas to enable us to develop more sophisticated systems more easily. Components, modules, services, these are all some level of wrapping and abstraction, but even those are all built with these crude tools. In 30 years, we’ve basically achieved P-code and automated memory management. Not good enough.

Currently playing in iTunes: Pacific Coast Party by Smash Mouth

Leave a Reply

Your email address will not be published. Required fields are marked *