Ruby on Rails Development: Death to all Hobbyists
Ruby on Rails is the most hyped about technology in modern programming since the days that XML started passing the lips of CEO's who just "had" to join in on the latest round of buzzword bingo.
I didn't believe the hype initially. By the time Ruby on Rails started to gain traction, I was hip deep in Mono development (the open source version of .NET, which could run on Mac OS X and Linux), and really had no desire to pick up "yet another" framework to master. I was familiar with the Ruby programming language, having programmed with it on several occasions, but for pure web development, I still stuck with Perl or .NET. It wasn't until I first viewed David Heinemeier Hansson's now infamous screencast of programming a weblog in Rails that I decided that this framework definitely needed some attention.
Ruby on Rails is one of the fastest and most efficient programming languages in terms of the development cycle. This doesn't mean it's the fastest running language - nor does it mean it's the most efficient language to use – but it does mean that when it comes to the life cycle of application development Ruby on Rails can get you to the endgame faster than most.
Rails is also a very human intuitive programming language. This means that while planning out your functionality or reviewing code, the code will read like the English language in most cases. Oftentimes you can "guess" at how something will work and you'll be right. Other times you can easily track down issues in your code – or just functionality that you’re looking for – by reading through it with ease.
The speed of development and intuitive nature of the framework are two of the largest reasons that Ruby on Rails is such an attractive language for programmers to develop in, and for businesses to request as the backbone of their own development. Rails’ fast development life cycle means less expense on programming and faster ROI. Or does it?
When the worlds of web development and programming converged to produce dynamic web applications that intermingled frontend design code (HTML) with server side technologies (Java, Perl) there were four main competitors for the title: Sun's Java ServerPages, Microsoft's Active ServerPages, ColdFusion and PHP. Out of these four most popular dynamic languages, PHP stood as a web developers dream. With no compiling required, no real tag syntax and a lower barrier of entry than most others, PHP became the de facto dynamic language on the Internet. This doesn’t mean that everyone was using it. To the contrary, at the time, most big businesses were heavily invested in Java Servlet and JSP technology. But many small and medium sized businesses couldn’t cope with the cost of expensive Sun Microsystems or IBM tools. Instead, they started looking for a more cost effective alternative that would "just plain work." PHP filled the void not only for small and medium sized businesses, but also for young hobbyist developers looking to program their own web applications for personal or community use.
The problem with PHP began to arise when it became obvious that too many hobbyist developers were passing themselves off as experts. PHP is an easy language to learn, but learning a language and mastering it are two different things. The Internet is now filled with applications, scripts and even quite a few development houses that were created by what some in the technology industry refer to as "script kiddies." Script kiddies are hobbyists that learned the basics of the language necessary to get their project complete. This doesn't mean that it's efficient. This doesn't mean that it's secure. It just means that it's done. These same script kiddies can often be seen trying to sell their services for development projects.
All of this has ultimately given PHP a bad name in some circles. PHP doesn't have a clear separation of frontend (view) design and backend (controller, model) programming. It also isn't as secure as many other languages - originally more focused for quick integrated development rather than fully fledged web applications; and although PHP has grown and evolved into a more robust and secure language compared to its earlier versions, the script kiddies haven’t evolved with it. The result is bad, uninformed programming, and poor code that could ultimately cost an individual or business in the long run.
I bring up PHP because in this Web 2.0 (yet another buzzword) happy world, Ruby on Rails has taken the place of PHP as the script kiddies' dream tool. Consultants and code houses wow prospective clients with the speed of development factor, while secretly tapping their heels in the air at the ease that Rails brings to them during programming. But just as PHP has spawned a cadre of hobbyist programmers that lack a clear understanding of software architecture, Ruby on Rails has spawned hobbyist programmers reliant on the framework to do their work for them. Sure they can build generic applications fast and with a smile – and even with client approval on the glimmering surface of the finished product – but this doesn't mean the web application is secure, optimized and ready to produce a significant ROI.
I don't run into many Ruby programmers. I run into Rails programmers. Despite Ruby on Rails being written in Ruby, a Ruby on Rails project consists of a tight wrapping of the application within the framework. A Rails application will be programmed with mostly Rails framework-created methods and methodology. You have to "learn" the framework to be an effective Rails programmer, which is true with any framework. Ruby on Rails is so easy to work with, however, that it’s easy to jump on board and start creating applications without ever being familiar with the Ruby language itself. This is where the problems start to occur.
It's one thing to know how to program. It's another thing to know how to program effectively, and solve real world problems. Ruby on Rails does a great job of giving programmers the tools to start an application, but only real problem solving skills with help them finish that application, and finish it to the clients’ satisfaction. Truly innovative tasks are not accomplished "out-of-the-box." Ruby on Rails can probably take you 80-85% of the way there, but unless a programmer actually knows the underlying technology (Ruby in this case) they’ll be ill-equipped to solve the problems that occur when functionality requests from the client lay outside of the realm of "out-of-the-box" Rails functionality. It is the solution to those problems that separates an average application from one that makes a client successful and distinct from their competition. This is why fundamental understanding of software architecture is such an important thing.
A low barrier of entry for a framework is not always good for businesses seeking technology solutions. It can sometimes actually hurt them when they're seeking a company to solve their technology needs. There are too many script kiddies rampant on the Internet professing expertise in Ruby on Rails, but without any solid understanding of the actual Ruby language, and the methodologies of successful software architecture. Small and medium sized businesses have very little wiggle room for error when investing in their technology. The technology must be efficient from top to bottom, and that cannot be accomplished if a business makes the mistake of relying on an individual or organization that falls too closely in the "script kiddies" category. A business must be able to rely on a sound technology company that knows how to solve problems, not just piece together parts inside of a framework.
