Obie Fernandez recently launched his new services company, HashRocket, and initially it seems the 3-2-1 Launch service that promises to have a production app up and running in 3 days (with 3 weeks of requirements gathering) has gathered most of the attention. This is super, and a great manifestation of the productivity that us Rails people have become enamoured with.

But I think the other service is more interesting. Rescue Mission will save your Rails project from disaster, and it’s an idea that I don’t think has been talked about enough in the Rails community – what do we do if a project is not going to plan? Obie and Co will no doubt find steady work in this area.

I think this topic of project rescues naturally segues into an even more interesting area – maintaining existing Rails applications. To this point, a majority of Rails work has been actively building new applications. It’s the sort of work everyone enjoys. But we are coming up to a time where our older Rails apps are about three years old, and there’ll be a time soon when Rails apps need to be maintained by people who didn’t build them, people who have no history with the codebase.

How are we going to maintain these applications? Some of the ‘ancient’ (i.e. 18 month old!) Rails code I’ve seen (written by both myself and others) would make a modern Rails programmer shudder. Do we go through and rewrite this? Or should we just aim for test coverage and let old bad code lie. When we do decide refactoring is necessary, will our tools support us? And what about upgrading? Should we upgrade old apps to Rails 2? These questions are just the tip of the maintenance iceberg as well.

I don’t have answers, but my feeling is that Ruby will be a blessing and a curse when it comes to maintenance. More expressive code will be easier to maintain simply by having less plumbing and fewer lines of code, but on the other hand, our toolsets are nowhere near as advanced as a Java programmer’s toolkit, where maintenance is a way of life for many developers.