How I’ve Learned To Stop Worrying and Outsource Technological Decisions to Rails

David Heinemeier Hansson, creator of Rails, on stage at RailsConf 2008.  Photo by David Duncan Davidson In his keynote at RailsConf 2008David Heinemeier Hansson referenced one of the core tenants of rails: convention over configuration.  In that discussion, he expounded on the paradox of choice.  Generally we intuitively believe that choice is good, desirable, and laudable.   However, while we honor the ideals of choice and flexibility, we are quick to forget or even ignore the accompanying complexity and cost.  So in the heat of the moment when the crunch is on and we come face to face with choice and flexibility, we turn and seek solace from someone, anyone who can tell us which to choose.  At that instant, we regret it.  When it really comes down to it - we don’t want choice - we want a solution.  And Rails provides one.

Yet, I am increasingly buffeted by those singing the siren song of choice and flexibility.  It manifests itself in the form of a discussion over breakfast with some DataMapper developers.  ”DataMapper is faster.  It uses less memory, it’s more efficient, it isn’t as opinionated - you can configure it.”  Ding Ding Ding, that is the problem.  I don’t want to configure it.  I don’t want choices.  I don’t want to research, evaluate, and decide.  I don’t want Java and its infinite flexibility.  I do want to create killer applications.

The song doesn’t stop. It just changes channels, and guess what’s playing - Jumpin’ JQuery Jazz. “But JQuery is so much cleaner, it plays nice with others, it’s smaller, it’s built on css selectors, it’s unobtrusive.”  Wow - that’s really cool but what you didn’t mention is that it doesn’t work with the rails views and javascript helpers. And like a loving father who sorrowfully watches a wayward child wander in darken paths, Rails will let you override its defaults, constraints and conventions and wish you luck as you set out on your own.

By the time the Rspec retro reggae hits my ears - I just turn the radio off.  The music is giving me a headache.     

There is a reason that java developers are famous for developing frameworks rather than actual applications - they all get bogged down in the decision-making process.  I mean it is completely overwhelming.   They have to choose a web framework, a presentation layer, a database access strategy, a build system, a testing framework, a development environment, and find a way around or out of the train wrecks that are EJB and JSF.  Luckily, being excellent computer scientists they recognize the limitations of the current offerings and set off to fix them.  And that, ladies and gentlemen, is why we have Ten Thousand Java Frameworks And Counting.

So I proudly declare it.  I’m not a computer scientist.  I’m an application developer and entrepreneur.  I solve business problems.  I’m a Rails Disciple.  I embrace its constraints and conventions.  I love that it makes many choices for me.  I’m not blind and oblivious to new technology and I don’t claim Rails the victor in the discussion of technical superiority.  However, I will outsource many technical decisions to Rails and sleep all the better for it.  After all, if it works for 37 Signals, surely it can work for me.  

 


One Response to “How I’ve Learned To Stop Worrying and Outsource Technological Decisions to Rails”

Leave a Reply