Over the years, I’ve heard many arguments against such a model. I’ve even offered some myself, on occasions. I’ve come to realize that there are more advantages to a polyglot model than there are valid arguments against it.
First, let’s start with some of the arguments against this model:
- I’m having enough trouble finding developers with experience in language XYZ.
- I can’t expect developers to know more than one language.
- I can’t support multiple deployment environments.
- How do I support and provide governance over a multi-language environment?
Now, let’s look at some answers to these arguments:
- Finding developers that are open to a polyglot environment means finding developers that are curious tinkerers, who are passionate about technology. Giving them the chance to work in multiple languages in a given day, or even on a regular basis, helps to alleviate boredom – one of the key factors that opens the door to attrition.
- When developers work in multiple languages, they not only learn the new language, but also its strengths and best practices. They stop being a hammer operator and start becoming a craftsman, who realizes that there are certain tools that work best for certain jobs.
- Multi-language, generally, includes a multi-paradigm element. This allows your developers to approach problems from different angles. One will find that iterating collections is generally simpler to both code and understand with a functional language than an object-oriented one.
- Once you’ve become known as an organization that has embraced a polyglot (right tool for the right job) approach, you will attract interest from developers that are the curious tinkerers, passionate about technology.
- Management of deployment environments has become less of an issue as well. If you have, traditionally, been a Java shop, there are a multitude of languages that run on the JVM. The same is true for the .Net shop, where a multitude of languages are available for the CLR.
- Governance over a polyglot environment does present some challenges, but maybe it’s time that architecture join the rest of the IT organization and begins to take a leaner, more Agile approach and start utilizing the best tools and approaches, rather than just the (currently) approved ones.
- One final feather in the cap for a polyglot environment comes from the fact that it gets to the right tool for the right job and ensures cost effectiveness. Coding a web application in a Java web framework versus a web framework optimized for developer productivity such as Rails or Django, one will generally find the productivity gains from the combination of the dynamic language and the full scaffold sufficient to warrant investigation. After all, our job is more than just delivering software, our job in IT is also to deliver value.
So, now, I have to ask myself one more question along with the standard questions like what are the risks, is this design solid, is it secure, is it reusable? … and that is: Am I using the right tool for the job or do I only have a hammer in my toolbox?
Do you agree? Let me know…