Earlier this week I saw a presentation of Ruby on Rails, a relatively new web framework that’s favoured by developers seeking a rapid application development tool. Some sites, including Twitter, use RoR as their primary framework but it’s also used by developers needing to rapidly build site prototypes before production designs are signed off and release coding begins. Global recognition for this new framework beyond Twitter came in August 2006 when Apple announced that Ruby on Rails would ship as a development kit with their Mac OS X operating system.
What makes RoR suitable for prototyping is it relative simplicity, there is lots of pre-written code out of the box and RoR has ways of promoting code re-use. The presenter made a comment which is common to modern languages that if you write a whole page of RoR code then you’ve probably missed a trick.
RoR is a plug-in for a web server, for developers often Passenger, but can scale to Apache and IIS for more traditional production environments. The Fast-CGI plug-in is important recognition that while open source solutions helpfully promote and distribute the framework to new audiences mass production adoption will only succeed where integration with IIS is a given. IIS for the clients I work with goes far beyond being a web server host. Intelligent media streaming, caching, web service presentation and application hosting mean that IIS now replaces what previously may have been an array of utilities, operating systems or even appliances.
In summary, Ruby on Rails is a good tool for the software development lifecycle, rapidly developing your prototypes and potentially your gold release.
However, when I asked how RoR compared to similar technologies, when it would make an ideal tool and when something else would be more suitable I got don’t knows as my answers. The technologists loved the features and functionality but didn’t know their business value. This is quite common in the technology world.
A new release, a new model, a new variant appears and we feel compelled by opinions to upgrade before we even know what new functionality now exists, and new functionality which my project or business actually requires. If you can make the success of adoption someone else’s responsibility (outsourcing, managed service, cloud service etc) then that’s great, consider the new functionality as a slick bolt-on to your current environment, otherwise you are potentially exposing yourself to a new cycle of business risk, bugs, up-skilling and regression testing etc. Sometimes this can be worthwhile (IIS 6 to 7.5 upgrades, lightweight RAD tool adoption) but before you saw phwoar isn’t this great ask yourself when do I need this and why? The same process can also save yourself a lot of money when shopping too!