FiveRuns Blog

This week, coming from sunny Orlando and the sold-out acts_as_conference event, we’re happy to bring you this week’s Rails TakeFive insights from Robert Dempsey.

In addition to his full time work at leading Rails development firm, Atlantic Dominion Solutions – ADS, Robert is the founder and Director of Rails For All, a not-for-profit organization dedicated to promoting the use of Ruby on Rails. FiveRuns is proud to count ADS as a partner.

FiveRuns: Welcome, Robert. What was your first “ah-ha” moment with Ruby and/or Rails and when did you know that the framework was a good fit for your organization?

Robert Dempsey: Our first experience with Ruby on Rails was converting a PHP app. We had done three months of PHP development and recreated the entire thing in Rails in less than one month. It was at that time that we decided to move 100% to Ruby on Rails development. That was more than two years ago. Interestingly enough, as Rails has matured as a framework, we have matured as a development firm, moving from waterfall methodologies to agile development. Rails and agile mesh perfectly.

FiveRuns: People always talk about “convention over configuration” as a paradigm that is central to why Rails works as well as it does. Can you say a little more for the newbies out there about why this so important?

Robert Dempsey: When people ask me why they hear that Rails apps are built so much faster than using other languages/frameworks, I state “convention over configuration” as the main reason. While the statement is a poke at Java applications and the large amounts of XML files they use, it is very important. When we create a Rails application, we can expect there to be a certain folder structure put in place, with each file type (model, view, controller, etc.) being in its proper folder. While that seems like such a simple thing, it becomes huge when you join a new team or take over an application from another team. There is less learning curve as you already know what is where. You don’t have to learn new conventions, they are already spelled out for you.

FiveRuns: When is Ruby on Rails an appropriate choice for application development in the enterprise?

Robert Dempsey: Wikipedia defines enterprise software as, “software that ‘solves’ an enterprise problem (rather than a departmental problem) and usually enterprise software is written using Enterprise Software Architecture,” which it defines as “the description of the current and/or future structure and behavior of an organization’s processes, information systems, personnel and organizational sub-units, aligned with the organization’s core goals and strategic direction.” Rails definitely fits into that broad context. As an example, we created a claim tracking system for a large US-based insurance company using Rails. Enterprisey? Definitely. The goal of software is to model business processes and to solve business challenges. Folks are doing this all day for companies of varying sizes using Rails.

FiveRuns: John K. Waters recently summed up a panel from QCon San Francisco in which he asked “So why is this free, open, easy-to-use, passionately advocated Web-app framework having such a hard time gaining serious traction in the enterprise?” What do you think?

Robert Dempsey: While I have heard of Rails and other open source projects being shot down due to the inability to buy a license or get support from a large vendor, I think the main reason there isn’t more rapid adoption of Rails in the enterprise is due to the paradigm shift that Rails requires. Rails follows a certain set of standards, methodologies, and ideas that may not fit with established practices. However, Rails is only three years old. Give it more time, and we will see increased use of it. Rails 2.0.2 has large performance improvements, as does Ruby 1.9. Both will keep getting better while adoption increases. The more stories we hear about proven, large-scale Rails applications, the more it will be accepted. Did I mention that we wrote a claim tracking system for an insurance company? That seems “enterprisey” to me.

FiveRuns: What do you think about Curt Hibb’s opinion that by running Ruby under the ever-present JVM it is now much easier to sneak Ruby into companies through the back door, especially since Ruby can call and inherit Java (and vice versa)?

Robert Dempsey: While I have seen a number of very successful projects that combine Ruby on Rails and Java, each running on their own servers in their own environments, I got very excited when I started to use JRuby and Glassfish. It was great to be able to package up an entire Rails app and with a few clicks of a mouse have it deployed to an application server, which in this instance was Glassfish. Rails deployment has always been an issue, one which Java solved a while ago. Further, Java has a lot to offer. If I can use the best of Java and code in Ruby then I have two tools in my belt that will help me create serious business applications. If the JVM and JRuby makes it easier for us to get Ruby in the door then I am all for it.

FiveRuns: Is JRuby going to increase adoption with more mainstream developers?

Robert Dempsey: I’m very excited about JRuby. There are many Java shops that are looking to introduce Ruby and JRuby is the way that can happen. I believe that much like Rails helped increase the use of Ruby, so too will JRuby. I have always been a big proponent of the right tool for the right job. Both Ruby and Java have their place. When used together, they bring the best of both worlds to the table. As for attracting mainstream developers, that might take a while. I have seen in-house Java developers sneaking Ruby in using JRuby, and I am sure that ThoughtWorks is working with it quite a bit, but that is the extent of what I have heard, so far.

FiveRuns: Have you ever been part of a “Big Rewrite,” as Chad Fowler has put it? What advice would you give to anyone about to take on such a project?

Robert Dempsey: We started to work with a company on a “Big Rewrite” project. Before getting into it we wanted to ensure that the client was doing it for the right reasons, and that there was buy-in on all levels of the organization. In this case, those right reasons included the current code base being unstable and difficult to maintain, the current code is many versions behind and they wanted to start fresh with a new language (and liked Ruby on Rails), and Rails fit the application. We also started into the project as if we were working on a brand new application that has never existed. We created a fresh set of requirements written as user stories and put them into a backlog, in preparation for client prioritization. My advice is to approach a project thus: ensure you are doing it for the right reasons, get buy-in from all impacted parties, start with a fresh set of requirements, and refer to old code as reference material only.

Beginning a career in IT more than 9 years ago, Robert Dempsey transitioned to web application development in 2001, teaching himself PHP and VB.NET. In 2005 he dove into learning both Ruby and Ruby on Rails. What he found caused him to change the focus of his company, Atlantic Dominion Solutions to a full-service Ruby on Rails development firm. In March of 2007, Robert launched the not-for-profit Rails For All, with the purpose of giving back to the community that had given him so much. Robert gives frequent talks at local Ruby and Java user groups, teaches the basics of Ruby on Rails, publishes articles for Amazon Web Services, and mentors new freelancers.