The ELC Community Blog

A knowledge exchange on Ruby on Rails and Agile Development

Its about the team

by Ryan Garver on October 16, 2007

A few weeks ago Derek Sivers posted an opinion piece on O'Reilly's Ruby Blog. The article basically raps on Rails for not being flexible enough to meet Derek's needs in his application. As the comment thread grew it quickly became clear that the root of the problem was Derek's lack of knowledge of the Ruby on Rails paradigm. At the end of the day, I don't think it is appropriate for me to lecture on the "right" and "wrong" tools for a job. I have not tried every language or framework; and if Derek is hacking the thing out by himself, then by all means use what you're comfortable with. What I can talk to is one issue that didn't get as much attention as I think it should have in the flame war that ensued. Maintainability.

When building applications where more than one person is involved there is an important question to ask when choosing a tool. Can your team maintain the work product? And, are they happy while they do it? Both of these questions are important to long term project success.

The first question addresses the ease of maintenance. This is the subject of numerous punch-lines and has become the hallmark (not in a good way) of a number of languages. Project maintainability is of particular importance when agile methods are being applied. If a strong up-front design phase is not present then you must be able to make changes efficiently, effectively, and frequently. The agile community would call this refactoring. Clearly this mentality necessitates high maintainability in the language, frameworks, and tools that are being used. Most languages and frameworks historically considered "enterprise grade" (think Java or .Net) leverage refactoring support in the IDE. This is necessary because those languages tend to have significant syntactic bloat. Take a look at "Hello, World!" in Java to see what I mean.

Ruby on Rails has very high information density which allows for concise and clear communication of functionality. The language syntax is very flexible. If you look at ActiveRecord or ActionController you will see constructs that implement complex features in a matter of a few lines. If solving a problem prevents you from writing code that is easily understood by other programmers then the language and libraries are not doing their job. Ruby has the flexibility to support this and Rails provides the libraries to facilitate clear communication of ideas between programmers through code.

The second question speaks to team morale. There is a reason that Ruby on Rails is particularly popular in the startup "Web 2.0" space. If you were a programmer working with your friends in a garage you would choose a language that was fun. But this question goes deeper than "is it fun to program in the language/framework?" Looking at it from the direction of maintainability, can we have an enjoyable experience while maintaining and improving an existing code base? This is impacted by a number of factors beyond language syntax, such as how difficult changes are to make, or how fragile the code is. Ruby is a fun language to program in. Rails is well structured and handles the boring details that never change for you. Projects in Ruby on Rails generally age gracefully. You will rarely see the addition of a new feature in Rails require a massive cascade of changes through out the code base.

Ruby on Rails has succeeded because it can answer both of these question with a resounding yes. Doubly so when the community values are embraced. Convention over configuration; Don't repeat your self; Write tests. I have never felt that PHP facilitates clear communication between programmers. Nor have I ever felt that maintaining PHP was anything close to an enjoyable experience.