For most of my two years on the Mingle team, we used an upgrade from Rails 2 to Rails 3 as a mythical future milestone, mainly used as the punchline of jokes, e.g. "We'll get around to that feature request right after we upgrade to Rails 3." However, when I took over tech lead duties I had the opportunity to revisit many of the technical decisions we had made. Rails was the first topic I approached. I'll cover the technical nitty gritty of the approach we'll be taking in a later entry but for now I want to talk about the Why.
The Abstract Reasons
There are a lot of compelling reasons for upgrading the framework upon which you've built an application. Many of these reasons are a bit abstract. They are taken for granted as true by most developers I've worked with, at the very least as ideals. I believe that these are all perfectly valid reasons to drive an infrastructure upgrade:
Community support. If you use an old version of an open source project, then you sacrifice many of the benefits of being part of the open source community. I've blogged about this issue separately so I won't repeat myself here. The key point is that if you're not keeping up with the community, you've essentially got yourself a private fork and supporting it is pretty much your responsibility.
Developer morale. Developers like to work with the shiny and new. Mingle is built in San Francisco. Even Rails 3 is yesterday's news in the startup saturated tech culture around here. Being on Rails 2 is like trying to hire for C++.
Avoiding obsolescence. This is quite similar to community support but is much more sinister. A common excuse the Mingle team used to avoid upgrading was that we had more important things to do: namely, build visible functionality for our customers. Unfortunately, this becomes a hole you dig yourself into. It's basically like forgoing the payment of a parking ticket because you'd rather buy other things with the money. A month later, penalties have accrued so you owe more, but nothing else in your life changed. You make the same income and have the same desires to spend the money on beer and food. Obviously, you make the same decision. And the same decision the month after that, and so on. Then eventually you owe hundreds of dollars and your car is towed. The technology equivalent to the point at which you can no longer recover I'm calling obsolescence.
The example I always use for this outcome is one of my first projects as a developer. I was tasked to get to the bottom of why we could no longer compile some ActiveX controls used by our otherwise PHP-powered web app. I rolled up my sleeves and tried to figure it out. I used the exact versions of Visual Studio that used to work. I played with the version of every library and dependency I could find. I created a virtual machine with an older version of Windows XP and left it unpatched. All in all, I spent about three weeks until I had exhausted all possibilities. This project had become obsolete. In the end, we just decided to bite the bullet and implement the controls in a new language and framework. While you could say that the main lesson here is to go the DevOps route of versioning everything and avoiding snowflake environments, I still feel the primary reason is to keep integrating your code with The World. Otherwise, sooner or later, your car will be towed.
The Concrete, Immediate, Business Case Reason
While I would argue the above reasons apply to all software projects of any longevity, as far as why the Mingle team made the decision to move to Rails 3 now in 2012, it basically came down to one fact: we couldn't use gems anymore. The community had long since shifted to building new gems and updating existing popular gems to support Rails 3.
When we finally made the decision to replace our homegrown and oft-despised search functionality with Elastic Search, we spiked out using gems to help us easily index our model records in the Elastic Search service and run queries against it. To do this, we ended up creating a proof of concept Rails 3 app pointing at our dogfooding instance database because none of the integration gems, not to mention their dependencies, came anywhere near working with our aging stack. We really liked the results of the spike, and chose to go with the gem elastic_searchable, but we weren't quite sure what we were going to do about the fact it didn't work with our stack.
We finally ended up forking the last version of elastic_searchable that worked with Rails 2, a commit circa March 2011, and spending a pair week or two implementing anything that had changed in the meantime. Meanwhile, Elastic Search continues to release new versions with performance improvements, bug fixes, and feature additions. The public elastic_searchable, Rails 3-only gem is updated to support all of these. However, our puny Rails 2 fork sits in stasis. The code is so different we can't merge in the changes.
Mingle was built as a Rails application for the precise reason it could move faster and leverage the latest technology in a more effective way than its competition. By staying chained to the past, we were squandering the benefits we might otherwise enjoy.
Now that we have decided to make the move, I'll continue to blog about the strategies we employ and how it all shakes out.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.