A guide for changing programming languages

Many projects will encounter a point of frustration with some aspect of Information Technology architecture and developers may clamor for a new technical solution. Changing programming languages may involve a significant rewrite of the software, which is a bad idea most times. However, if you are faced with a compelling technology how should a Project Manager approach the transition? Two personal examples may shed some light on the decision whether or not to change programming languages.

If your group develops web-based applications, you need to know about Ruby on Rails. It isn't magic, but spend a day with it and you will probably agree that it is the closest thing to magic you've seen in IT in the last few years. If this sounds like a lot of bravado, it is, but mine is just one of many voices in the crowd praising Ruby on Rails. Elegant and robust systems are built with Rails in a fraction of the time spent on previous platforms.

That said, if you manage an IT project with a web tier your developers may inquire about switching to Rails. What should you do?

In my group, we were about six weeks into developing a web-based tool when our lead developer, Erik Hatcher, suggested that we consider switching to Rails. Erik made the bold statement that in one week he could reproduce our current Java-based functionality in Rails. We had a little slack in the schedule so I suggested that he try it and I would evaluate the progress after a week. As it turns out, he exceeded the goal and today we happily churn onward with Rails.

For a different tale, a colleague heard of our good experience and was perplexed because a new developer on his team, who had inherited a Java code base, wanted to re-write it in Rails. I advised him to stick to the Java system for the following reasons:

  • The volume of code was rather large, having been developed over the course of a year
  • The motivation of the developer seemed to be a tad on the side of techno-lust, or at the very least, wanted to learn Ruby on the project's dime
  • Experienced Java programmers are easier to hire than Ruby hackers, as a general rule

None of these in isolation would be reason enough to stay the course but in combination, they signal for caution, chief among them the large volume of code that makes a proof of concept exercise untenable. The decision to change programming languages, databases and operating systems shouldn't be taken lightly, but when the issue comes up the approach should be analytic. Be wary of resume-driven development initiatives, architectural advice from vendors, marketing hype and buzzword compliance. That your development team is more productive with the new technology is all that matters.

I suggest changing architectures only when the following factors align:

  1. The technology is proven in your development environment
  2. The installed user base is small for your application
  3. You are still in a development or prototype stage that won't endanger a production system
  4. Your developers want to learn the technology for the right reasons and they have a firm grasp of the code base

Follow this model and you will avoid untold frustrations that lie in wait. Transitioning to Ruby on Rails worked fantastically for our group and it may well do so for yours as well, but proceed analytically and demonstrate value from the transition before making a full leap.