Brian's World

Web Dev

I had the opportunity to speak at a web development conference a few days ago. Unfortunately my words were not recorded verbatim, so I’ll try and reassemble them here. Ruby on Rails, and really any MVC style framework, were the hot topics like always.

It makes sense to me that an existing framework should be used if you are prototyping an application. Pushing an application into a production environment, especially one where you are expecting thousands of users, should force you to rethink your implementation. Personally, I am about 90% confident that rails, cake, etc will do what I want it to just fine for a few hundreds users. There are probably dozens of use cases where these same tools will scale fine to thousands of users, but unless I have a cake or rails contributor on staff, I cannot risk that decision.  My applications (assumed to be important) just cannot experience issues that I, or another programmer on my staff, have not coded in to our application or reviewed the code for [I would never pay someone to review the RoR code or anything like that].  If your applications are junky, say… like a Facebook application, then I say who cares.  You don’t really control the important end of the stick anyways.  Use whatever gets the job done well enough.

By the time your prototype (you might call it an ‘application’) is taking off, take some time to look at your implementation. I understand you have the smartest caching scheme in existence and you’ve done a super job with load balancing Mongrel, but are all the ‘DESCRIBE TABLE’ queries really the best use of your resources? Go ahead, if you have buckets of money to throw at hardware do it… It’s probably cheaper and easier than having to pay your people to think anyways. In my shop, after a prototype gets the final sign off and it looks like people actually want to use it, a php, python, or html/perl fork is immediately started.  I no longer have to guess what a framework will think of my application; I am telling my application how to think on my own.  Yes, this might mean I am hard-coding SQL and doing my own string escaping.  A security risk? Probably. But one that I have control over and can take responsibility for.

Don’t get me wrong here, I like frameworks just as much as you. In this “tight” economy a framework can be the most cost effective way to get a new product off the ground. Recognize though, that once it’s flying those training wheels are going to slow you down.

My favorite example, Twitter.  If you don’t know what Twitter is, you probably didn’t understand most of what I was just talking about.  Twitter is my favorite example for a few reasons: 1) It is written in Rails 2) The service is freakishly simple and 3) It did not scale gracefully.  It turns out people wanted to communicate in under 160 characters, and twitter was the hot way to do so.  I got onboard a few months ago, and found myself unable to use the service for a solid 2 week period.  Every time I had something to say, the tactfully designed error page was presented indicating “over capacity”.  While it was much more graceful than no response, or a standard 404 or 500 error page, it still carried the same effect to me; you can’t do what you want to right now.  Go away.  Of course, twitter had (and still has) no real incentive to be operational.. until they can make money of me saying short messages, its just costing them money.  It took twitter a few months of what seem (and continue to be) pretty solid re-architectural work.  Features that were initially available quickly were ‘disabled’ [read as: poorly implemented], and there were rolling outages amongst the rest of the features.  No, I can’t blame the whole thing on their choice of languages, but rails helped avoid some of the core thinking that I put in to every application I work on.  Crafting in  rails mostly avoids the whole database thing, and does a pretty strong job to avoid the whole “now which components will I need to include for this feature.”  I don’t mean to insult twitter.  I use it and it works great,  there are tons of other poorly implemented MVC framework applications out there.

You’ll still see me writing in popular MVC frameworks, but probably not for any application that I expect to ever take off.  In the freak chance there is an application that I do produce and keep in an MVC framework after its popular, you can be certain of one of two things.  You choose which is more likely.

1. I haven’t had the time to rewrite it.
2. I’ve spend more time than I should testing the framework.

Off topic: My annual Christmas blog will be arriving later this week.  My iTunes must be playing from my Top Music list, or the shuffle is treating me extremely well today.  I need to call Larry and be like “Hey, give me the name Bamnet back!”