Max Baker, a PHP developer trying to influence the powers that be at his company, recently wrote:

I’m currently a php/sql developer for a company and I think rails is one thing that can really get our development to the next level , but management says that rails is just hype and that building ajax rich applications is much easier using php and java script , etc… I’ve shown them applications with rails and such, things like text mate, and how fast and easy things can be done to no avail.

I really wanna switch and join the rails community, but I don’t know what to tell them. What should I do?

With the release of Rails 1.1, rails is finally reaching an outwardly visible stage of maturity. Because of that confident-looking version number, it’s now quite a bit easier to rebutt the first thought to grip management—that Rails is in its infancy, and that there is no stable code base.

So what other concerns are there? I tried to address some of them by relating my own journey from PHP to Ruby in my response to Max’s email:

To Max

It’s a privilege to share with you some of my thoughts on developing web applications in Rails–I was in your shoes not long ago, and I know what it feels like to be the “work horse” when it seems the reins are in someone else’s hands. All I can say is don’t lose hope–while Rails may be hyped right now, it’s not *just* hype. It will prove to be the obvious choice some day, but we’re still riding the early adoption curve right now, so there is a natural resistance to its novelty.

Letter to Management

About 2 years ago, I was hired by a small local web dev company to build and maintain PHP applications. We had a few in-house libraries that aided our development–things like database connection and querying libraries, for example–but no framework that we had standardized on. Some of my responsibilities included maintaining legacy code, training new hires, and leading the development of new applications. Perhaps some of the things I learned there will be helpful to the managers at your company:

1. Ruby is easy to learn

One of the main concerns brought to my attention by management when I worked to bring Ruby on Rails in to our shop was that there are lots of PHP developers out there, and very few Ruby developers. My response was that while that is the case for now, it doesn’t address the more pressing concerns for a development team.

For example, there is always a lead-in time for someone new on the team. How long does it take them to get up to speed with the language, framework, and environment? In my experience, anyone who understands one or two programming languages already will have no trouble picking up on Ruby. In fact, it took about the same time for a PHP developer to begin to be productive using our in-house libraries as it did for a PHP developer to begin to be productive using Ruby and the Rails framework (2 weeks).

In addition, the best practices that are encouraged by the Rails framework actually led to *better* developers in the long run. Those who adopted the agile methodology of Ruby on Rails by testing their code, refactoring, and using tools such as version control were, in my opinion, more valuable to the team.

2. Ruby is a swiss army knife, PHP is a hunting blade

While there’s no doubt that PHP and Ruby are both stable, capable languages, Ruby has some real advantages. It’s namespaces lead to more modularized code. Its closures lead to more code re-use. And its terse syntax makes it possible for even non-programmers to understand a surprising amount of it. In short, it gives developers more choices and more tools when solving problems.

While PHP has some advanced features that come with a late-bound language, it is not as well thought out, nor as self-consistent as Ruby. It require more brain-power to remember the thousands of function names and subtle differences between calls. (Do you pass “strstr” the haystack or the needle first?) In the end, programmers find that there is a “cap” or ceiling that they reach in PHP much sooner than in Ruby. In addition to the brainspace issue, there is the pure limitations of the language. For example, one of my friends–a developer of a Rails-a-like in PHP called Trax–told me that the lack of namespaces in PHP made it necessary to tack on prefixes to variable names in order to prevent clashes between modules. He has since begun to develop using Ruby on Rails (though, from what I understand, he is simultaneously working on Trax).

Fred Flinstone might be happy with a hunting blade, but if you want MacGyver on your team, give him a swiss army knife and see what he can do.

3. You definitely want your developers to standardize on a framework

Having dealt with several projects that use different approaches and techniques to get the same things done, I can recommend with confidence that you want to standardize on a framework. It just makes sense–your developers will be able to re-use more code more often, and there will be a common knowledge-base from which they can share tips and tricks. PHP is not a framework, nor does it offer guidance when making decisions that have been made countless times before. While there are a number of PHP frameworks out there, I have not found one that I can recommend as highly as Rails.

UPDATE: See Ruby on Rails from a Business Perspective for more on this point.

4. The Ruby on Rails framework gives your developers an edge

Because of the grass-roots support and energy surrounding Ruby on Rails, many, many brilliant web developers are contributing code and ideas to each other and to the Rails core on a daily basis. Developers who keep abreast with these new ideas and solutions to common problems have the benefit of “wisdom beyond their years” during the development cycle.

Additionally, there are a number of best practices and standards that are embedded within Rails itself that guide and influence developer decisions along the path to deployment. For example, separation of concerns using the model-view-controller paradigm; separating out the test, development and production databases; using fixtures for unit testing; the easy availability of integration testing (Rails 1.1), and the easy integration of Capistrano for deployment to multiple servers, to name a few.

I believe the productivity claims of up to 10 times *can* be true, but only in some cases. For example, I built “Family Connection” (a web-based family communication tool) in a day. On the other hand, when there are new problems to address or challenges that go beyond the wisdom of Rails, development can be much slower, perhaps equal to my previous PHP development speed. In any case, I’m much happier using Rails.

5. Programmers are more productive when they’re happy

A final note to those who are in a position to decide between one application framework and another: consider your developers feelings. If you see a flash of passion in their eyes when they talk about a framework, pay attention. You may or may not be intimately aware of technology trends, so trust your co-workers instincts. Programs may act mechanically, but humans do not. Go with the passion.