Softies on Rails Interviews: Orbitz 9
Orbitz is one of the largest companies in the online travel business, and from a web development standpoint, heavily invested in enterprise technologies like J2EE and Oracle. So I was pleased to learn that over the past several months, a small team at Orbitz has been working hard on a project called Traveler Update (maybe you've seen the TV commercials), and it's built entirely with Rails. I recently had the pleasure of meeting Doug Breaker, who's led the team at Orbitz through the project's development and recent launch.
Thanks to Doug and his team for this e-mail interview.
Tell us a bit about what your service is all about.
The product we launched on Rails is called Traveler Update, you can find it at http://updates.orbitz.com on the web, and http://mobile.orbitz.com on your phone. We set out to make peoples' day of travel less stressful and more enjoyable. The site combines a bunch of real-time, and near-real-time travel condition information, with updates and tips that travelers send in while they're traveling. One the day of your trip, you can go to the site to get your latest flight status, the airport status from Orbitz's team of air traffic experts and the FAA, live traffic delays, the latest weather, average security line wait times from the TSA, parking and wifi guides, and updates and tips from people actually traveling. All of the info is available both on the website, and on the mobile site.
Orbitz is one of the largest online travel agencies, we sell millions of airline tickets, hotels, and car rentals a year. Unlike other online travel agencies, we staff a seasoned team of experts that monitors nationwide travel conditions for our travelers around the clock, every day, and alert our travelers when conditions warrant. We wanted to build on this legacy with Traveler Update by allowing travelers to help each other out.
As you're primarily an enterprise Java shop, what was the primary motivation for you to explore Ruby/Rails and to build your app using Rails?
It actually a bit of a strange story. Before becoming a product guy at Orbitz, Doug was a .NET developer at a previous company. He was working on some personal projects and got really frustrated with .NET, did some searching for something better, and found and fell in love with Rails. After joining Orbitz' Product Management group, he continued to play around with Rails for small prototypes.
When we got the idea for Traveler Update late last year, he actually put together a really simple prototype in Rails, that was used to show off the concept to management, and build support for the project. Even in its ugly form, it stirred excitement, which led us to hire a Rails consulting firm to flesh out the prototype further. Doug looked specifically for Rails firms to do the work, since he had done the initial prototype in Rails, and wanted the full prototype done quickly, and wanted to be able to take and possibly use the finished code once they were done. By early this spring, the outside firm had completed the prototype, and our internal developers were ready to work on the product.
Initially, development planned to build the site on Orbitz' new global platform but also took a serious look at Rails based on the momentum the prototype had achieved. When the timeframe for delivering the project on our Java platform stretched out past when the business wanted to launch, all eyes began to focus on Rails. Timm had also been working with Rails for some personal projects the previous year and was as excited as Doug to campaign for Rails within Orbitz. After more backing and enthusiasm was gained from upper technology management, a dedicated development team was formed to work autonomously on the project. We were tasked with the challenge of seamlessly pairing up the Traveler Update site with the existing Orbitz.com site. The model has worked so well that other teams within the company are being formed in its image.
Tell us a little bit about your team... and how long it took your team to go from concept to launch.
The core team worked using agile development practices to match the philosophy of Rails, a change from our normal style of work. We're all full-time at Orbitz and consist of two product managers, an information architect, a designer, two rails developers, a UI developer, and of course a quality tester. We also had Marcel Molina, a member of the Rails core team, on-site for training and consulting early in the project to help kick-start our RoR knowledge.
Requirements writing began in January, but we switched to a feature-driven development model within a month, a move that made everyone happier. Since we're still in a public beta stage, there was no hard concept of 'done' per se, but we felt comfortable enough with the progress to launch over Labor Day. We actually could have launched earlier, but held off to better coincide with peak travel season. We continue to iteratively improve the site with a new release every two weeks.
Were there any particular challenges you faced because you chose Rails? Scalability? Learning curve?
As with any brand new application, we've learned to scale through caching and distribution as usage increases. We continue to stress test and load test the site with every new iteration to find bottlenecks and optimize our application and workaround the limits of ActiveRecord. Orbitz is heavily focused on the MVC architecture so many of the best practices of Rails were easy transitions. The lightweight and flexible nature of Ruby and IRB have been a joy to work with, though it does have its quirks at times.
Deployment... did you choose to try and fit your app into Orbitz's existing infrastructure or outsource it?
Rails has a growing influence among Orbitz developers for both internal and external applications. While Rails is now a mature platform for development, there is still a lack of information and support for operationalizing an app within a large enterprise. Our infrastructure group preferred to host it externally with a dedicated Rails host at first. We continue to evaluate where the tipping point is for building an in house Rails infrastructure.
What's next for your team?
We'll keep working on making peoples' day of travel easier and less stressful. For the next few months, that means releasing a couple of features we're pretty excited about, and making improvements based on user feedback. We're pretty excited right now because we just launched an Orbitz text messaging service where you can text Orbitz (shortcode 672489) to get flight status, the airport delay information, and current weather conditions. Longer term, we want to keep learning from our users and build features that help them on their day of travel. It's hard to say what direction the site will go in until we see it, but we have some pretty good ideas about integrating further with people's existing travel itineraries, flight tracking, supporting more airports, and providing more social features.




That's such an awesome story. Truly a fine example of how to introduce AND prove rails for big business usage. For any trolls that may be lurking saying to themselves "how did they prove it?", I have this to say.
J2EE wasn't "proven" out of the box. Someone along the way got a prototype together (just as they did with Rails) with all the bells and whistles needed to make an impact on why it was the "right choice". That's exactly how the ball should get rolling towards new platforms. When things get done quicker the people holding the dollars are happier. That is one of the foundations of Rails.
Great story guys.
/rant
I'd be interested to know if the dev group at Orbitz has any plans of Rails deployment in the future using JRuby since they have an existing Java Infrastructure and investment already.
Forget Ruby. I wonder how many Lisp programmers there are at Orbitz. :)
http://www.paulgraham.com/carl.html
I'd like to have heard more about how Orbitz are implementing feature-driven development for this project as I would like to use the feature-driven development approach with a Rails-based project.
I think J2EE fits such company, and Rails also fits it. Rails would make their life easier.
Feature driven development sounds interesting for me.
Thanks, Mike
I read this and was actually kind of sad that I had no one left to convince that Rails is a valid development choice. Normally I'd send links to an article like this to a handful of decision-makers, but they've all already been convinced :)
I agree with Matt Blodgett - forget Ruby!
By immersing ourselves meditatively in the general intentions of transcendental subjectivity, we discover that experiences become adjusted to, by conscious conversion into the corresponding cogitationes, modes of consciousness.
Our understanding, when thus treated as our faculties, occupies part of the sphere of the never-ending regress in the series of empirical conditions concerning the existence of the paralogisms of natural reason in general.