In our last post I fawned over Ruby on Rails (RoR) like a schoolboy smitten by the new girl (let’s call her Ruby) at school. So, like the schoolboy’s heart wrenching realization that he mistook Ruby’s “hello, world” smile for a tender “will - you - be - my - boyfriend” countenance, I present a handful of potential RoR letdowns.

Skills Demand > Skills Supply …There appears to be considerably more demand for Rails programming than there are Rails programmers (irrespective of whether they are good programmers or mediocre ones). The theoretical speed of development and speed of enhancement (read: potential cost saving) as well as the trendiness (let’s face it) of Rails has inspired a legion of business visionaries to increase their demand for Rails programmers in order to get their own facebook-meets-amazon mind bender to market faster than the other guy.

Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 - $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours]

The Visual Basic effect … A corollary to the fact that “pretenders” are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases. Like Visual Basic in the mid/early 1990s, Rails allows non-computer scientists to put together seemingly impressive applications. However, as a project progresses or application matures the truth becomes clear: (1) Rails helps bad coders write unscalable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.

No Swiss Army Knife … Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases. Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you’ll need to either (a) look somewhere else (b) write it into the framework (not likely as the shepherd of the framework are zealots and opinionated about protecting it from “unintended uses”) or (c) find a way to integrate with other technologies which support your business requirements.

No Throat to Choke and a Chasm to Cross … If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice. There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint. This makes adoption of the technology and its ability to cross the technology chasm questionable. Rails is still early on the S-curve. It may make inroads into enterprise application environments the way Linux did through techie revolutionaries. However, for it to truly become a technology that is well understood, well-supported, and, consequently, well entrenched, it will need the backing of a behemoth or two. Perhaps RoR will gain the support of IBM or an equivalent, but the backing of a programming framework — at least on the surface — seems a heck of lot more pock-marked with landmines (variability in installations) than supporting and advancing the kernel of an operating system that has been in existence for decades.

The Java Defense … Perhaps the biggest reason to not choose Rails is, well, Java. The “old guard” Javaists are adapting. They may not be benefiting from the “hoola hoop” craze that is all things Ruby. However, they’re not taking the RoR attack lying down. In fact, in a very Zen-like fashion, they are borrowing from the “one thing well” manifesto of RoR to develop equivalents including Groovy on Grails, Trails, and the like (We’ll write about some quantitative benefits of these developments which we’ve seen first-hand in upcoming posts; suffice it to say, Groovy/Grails is proving itself to be a formidable challenger). In enterprise-friendly terms this means companies will be able to “maximize and enhance their existing Java technology investments.” And, with Java you get the Swiss army knife.

– ALTERthought

Tags: Grails