Polyglot Programming: When all you have is a hammer…

hammer-nailIt’s been said that if all you have is a hammer then everything looks like a nail! Perhaps, this is part of the reason why I’m seeing more organizations move to a polyglot programming model.

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:

  1. I’m having enough trouble finding developers with experience in language XYZ.
  2. I can’t expect developers to know more than one language.
  3. I can’t support multiple deployment environments.
  4. How do I support and provide governance over a multi-language environment?

Now, let’s look at some answers to these arguments:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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…

Sogeti Labs


SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *

5 + 8 =

  1. Julya van Berkel May 1, 2015 Reply

    Hi Matthew,

    Thanks for your thoughts on this subject. The questions I ponder after this blog are linked to maintainability. I certainly agree with your assessment that you should look beyond just the hammer. Multiple tools however also bring along multiple libraries, coding guidelines, overhead, etc.
    Won’t you end up with a product that becomes difficult to maintain as most of the tools evolve in time? (A problem a hammer is less subject to).
    Many tools used (serious tools that also continuously improve themselves) come with new versions with deprecated methods, functions, etc. that eventually become obsolete.
    I’m not against bringing rigid single tool choices in my teams lives, but currently one of my teams is constantly battling keeping up with earlier tool choices that seem to affect our products majorly.