25 August 2005
Duane Gran emailed me with his thoughts on adopting Ruby-and-Rails into his shop, only his thoughts on the matter are a bit different from the usual rant; he's looking at it from the management perspective, and has some good ideas on when and why to adopt... or not to adopt... a new programming language.
Specifically, he spells out:
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:
- The technology is proven in your development environment
- The installed user base is small for your application
- You are still in a development or prototype stage that won't endanger a production system
- 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.
I like that list. I could probably add to it, with concerns whether the technology will be somehow integratable/interoperable from your legacy platforms, but I think that these issues are probably the first hurdle to pass--and, frankly, I think will be the hardest hurdle to pass, particularly given his caution against "resume-driven development initiatives". (I like that phrasology, Duane--don't be too surprised if you hear it on an $NFJS panel sometime. :-)
Last modified 25 August 2005