I was asked yesterday whether my new site, beta.ockhamresearch.com, was developed using Ruby on Rails.  In a very indirect way, sort of.  Ok, no, not at all!  Its Asp.Net MVC. 

Mvc stands for Model View Controller, a popular design pattern for modern website architecture.  I feel it is significantly more productive and effective than the page-centric architecture you find as the default in most web programming languages.  Ruby’s first popular website platform was Ruby on Rails.  There were other MVC implementations out there already for platforms such as Java and Smalltalk.  However, Rails maid it intuitive, productive and even fun.  This led other programmers to favor the pattern for developing websites (such as myself) and led to the development of Castle Monorail in dot net and other variants as well as on other platforms.  Many of these were ports of Rails for folks who weren’t able to use Ruby as their target language for one reason or another.  I had been using Monorail for some time when Microsoft announced the development of Asp.Net MVC.  Microsoft isn’t well-known for open development initiatives and often does things the Microsoft way rather than the conventional way.  The Microsoft Asp.Net team deserves much credit for the current quality of Asp.Net MVC and the integration of tremendous community feedback. 

Why not just use Rails?

Competency

I have very little experience with Ruby.  When I need to write some Ruby code, I need to look up each construct and find examples to work from.  I can code C# in the woods on the trunk of a tree.  Of course, compiling it would be a challenge.

Confidence

I know where Asp.Net and SQL Server limitations are and that the platform can achieve high performance.  I know that Ruby has known performance issues and no roadmap for reconciling these issues.  I’d rather not be the person responsible for overcoming performance issues on a production web server farm when we have paying clients expecting service.  If I can run a commercially supported platform with current licenses and support contracts, I have someone to lean on if anything goes wrong.  Furthermore, I can fix almost anything on Windows but my experience with Linux is feeble.  I aim to change that but, for now, I can provide confidence to my constituents that my web app will not fail due to memory leaks or unusual bugs that are not a result of my code.  Yes, there will definitely be errors in our future but using NUnit, Cruisecontrol.Net, WatiN, Visual Studio.Net and SQL Server will minimize the risk to a more than acceptable level.  I don’t know where to turn for the same thing in Rails.

Community

This is the most important factor.  The above two points are true for all the programmers I’ve worked with over more than the last decade.  We’re all very familiar and invested in Microsoft technologies.  There is no reason to switch if the features are available and productivity is commensurate with alternatives.  If I need help modifying some code because I have too much to do myself or we have an awesome contract pending, I don’t want to be searching in a small pond for good people. For every good programmer, there are a hundred terrible ones that will make a mess of my beautiful code :)  I can’t have that. 

Why Use Rails at All?

I can’t find current data that indicates the trend for what programmers are using but I can tell you my gut feelings and personal observations.  No community growth, in my technology career, has struck me with as much fervor and excitement as the Ruby and Rails explosion has.  These people aren’t Windows haters like Java programmers were.  They aren’t choosing Ruby because that’s where the jobs are (yet).  They are choosing Ruby because they get hooked!  They love working with it.  More often than not, a Ruby programmer dresses hip, is very laid back, uses a Mac, drives a Hybrid.  These are all traits of people with both time and money.  I want more time and money and would like to be hip.  However, I still prefer to burn more gas in exchange for fast times to sixty.  Glutinous, I know.

When do you switch?

Rails still needs to be proven in the enterprise.  My prediction is that this will happen in 2008.  Sites using Ruby on Rails will publish numbers and costs of operation that make it a very attractive alternative to the company standard.  The best place to try Ruby is on a new, small scoped project with just a few very close end users in a highly agile environment.  Don’t be silly and just announce that you are now Ruby and expect all your devs to just pick it up.  On the other hand, it would be a good idea to get some very intense training for your old school programmers (if you have them) because they are accustomed to working within the constraints of their strongly typed, compiled, high performance environment and will not naturally make the appropriate transitions necessary to achieve success, maintainability and scalability in a Rails environment.  Ask yourself if your compiled apps (yes, Asp.Net is compiled) are as fast as they should be and then ask yourself whether your app will still be acceptable at 50% of that speed.  On the other hand, if you have 80% of your hardware capacity remaining, you can probably virtualize and take advantage of your current infrastructure with very little cost.

Try it on like deodorant.  Give it a few days and try a few different activities and then ask your wife if your pits stink.  If not, take it a little further.

This entry was posted on Thursday, June 19th, 2008 at 8:43 am and is filed under Asp.Net, Mvc, Programming, Rails, Windows. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.