Rescuing Ruby on Rails Applications
Ruby on Rails makes web development look easy. This can be a good thing for people starting out, but a bad thing for businesses who are trying to produce real-world working code. I’ve consulted on numerous projects where developers thought they’d be able to “learn as you go” while attempting to develop enterprise-level applications in Rails.
The term “rescue” means exactly what it says – stepping into an existing project and finishing the parts the previous developers were unable to complete. Sometimes it means tearing down a lot of the application, or even starting over from scratch. As building contractors know, it’s very difficult to create a strong building on a weak foundation.
Rescue operations are inherently expensive. Usually, the client has already dealt with missed deadlines and over-budget development costs as the programmers frantically try to complete a fully working application. Choosing the right rescue developer is the key to keeping the cycle from repeating itself.
If you need a Ruby on Rails rescue, the developer(s) you bring in must be better than the developers you should have hired to begin with. To clarify, let’s say Project X needed a “great” developer in order to meet the development/budget goals. If you’ve hired an “okay” developer, you’ll now need a “stupendous” developer to get you back on track. A “great” developer is no longer good enough, because it’s much harder to fix a broken app (in a timely and cost effective manner) than it is to build it correctly from the start.
Here are some considerations when searching for a rescue developer:
- There are several testing suites available for Ruby on Rails. Be sure your new developer is comfortable working in the test suite that the original developer chose. There may not be much usable code there, but it may contain good info on the previous developer’s intentions.
- Ask potential developers if they’ll need to start the application from scratch. If you get a “yes” or “no”, this person is more concerned with landing the project. Questions like this require due diligence by a qualified developer. Be prepared to pay your favorite candidate for a few hours pre-contract, in order to determine the current state of the application.
- Understand that a rescue project is not easy for anyone. As a client, you’ll be overbudget and short on time. The developer will be faced with a mess they didn’t create, on a short time schedule. Communication is key. Pre-contract, evaluate just how easy it is to communicate with the new developer.
Once you’ve chosen your rescue developer, the time for doubt is over. Give that developer a clean slate, and try not to carry over any prejudgements from the last guy. It’s often a good idea to give the new developer more freedom than usual, so they can fix things in the best manner possible. You’re paying for their expertise, give them the freedom to use it.
I personally love projects like this because the challenges are always unique, and I consider it a personal mission to clear Ruby on Rails’ good name. I once had a client that hired me to finish an 18 month disaster in just six weeks. The plan was to launch the site so they could start rebuilding in a different language, because Ruby “obviously didn’t work”. Six weeks later they realized it was the developer, not the development platform, that was the problem.