Choose a number between one and 100
Every organization faces a dilemma when it comes to support for programming languages. On the one hand, there’s an understandable desire to standardize — a set of approved languages can help reign in maintenance costs and long term viability. But equally, many of us recognize the benefits of using whichever language the developer feels allows them to express themselves most eloquently.It’s a dilemma that has a personal element too. Some developers want to try every new language they possibly can — often out of genuine curiosity and desire to learn, while others may have half a mind on burnishing their employment prospects. For some, the joys of learning are found by going deep in one particular language, in a drive to become a specialist — or maybe they’re not confident about learning new languages.
This article explores ways of deciding how many programming languages is the right number for your organization to support. And while there’s no single answer that works for all organizations, I do believe it’s possible to get a handle on what the best approach for you.
One language to rule them all
Every so often, we come across clients and developers that believe that there really is one best choice when it comes to languages. In the not-too distant past, it was common to see organizations characterise themselves as Java or C# houses. More recently, we see this pattern with Node.js being used everywhere — with React for server-side rendering; with Kubernetes and Docker for orchestrating microservices; or using Node.js for serverless.There’s a lot to be said for having common tooling and workflows, not least in terms of maintenance and support costs. We’ve seen many large, complex organizations benefit from standardization. We’ve also seen start-ups turbo charge their growth by getting their devs to work within a common ecosystem. Even so, standardization has its limits.
Having just one language seems too self limiting. At ThoughtWorks, we’ve long been vocal supporters of the ideas of polyglot programming — we think that there are significant productivity benefits from choosing the right tool for the job.
General purpose vs special cases
As critics of polyglot programming like to point out the choice not to impose any restrictions paves the way toward chaos. Afterall, your ace programmer may well have written you the most exquisite system in Clojure, but if she’s the only one that knows that language, she’ll be wasting time on maintenance, not working on the next big project. And with scores of systems in different languages, your support costs will spiral.So, how many languages is too many?
At ThoughtWorks, many of our developers are polyglots — we work for a variety of clients, so it’s useful for us to have developers that are comfortable in multiple languages. But for our clients, it may make more sense to have a favored language or perhaps a small set of languages for general purpose application development.
Such choices do lead to compromises. For some large enterprises, it may be that their default choice of languages makes it more difficult and costly for individual business units to do their development.
At one client we worked with, I had devs coming to me tearing their hair out in frustration over the tech stack they’d found. They were certain that we could deliver a better solution, far quicker and far cheaper by switching to a different development paradigm. And they may well have been right. But what our devs, working in one department of this massive conglomerate, perhaps didn’t appreciate was this: the cost savings the client could realize across the business by standardizing dwarfed that one project’s costs.
Nonetheless, just because you standardize, it doesn’t mean you have to rule out experimentation for special cases. Take for instance, embedded systems or data science.
In cases such as these, your choice of language has real world consequences. While you can build an Internet of Things solution using almost any general purpose language — these things are after all, Turing complete — it doesn’t mean you should. Using something like Rust, which is ideal for embedded systems, has huge advantages for things like memory management and power consumption which can make or break IoT solutions.
It’s a similar tale when it comes to data science. Why would you not use something like Python or R? The libraries associated with these languages make it questionable to use anything else when you’re dealing with complex data projects.
We think that there are other special cases too. When it comes to language choices, we’ve seen a number of clients move away from their standard set because they think it will increase their chances of recruiting talent. By showing you can provide a career path — for say Clojure developers — you can make yourself a more attractive employer. You’ll no doubt know that attracting the most talented programmers is tough. Competition is fierce. So showing that you’re a forward thinking employer that will give developers interesting work can really help.
So within this context, each organization should think about what types of applications should fall outside the general purpose realm. You can allow experimentation, and you may want to add functional languages to repertoire of languages your organization is using.
These aren’t simple choices. You need to canvass views from both those at the coalface and those in leadership. And you need to be realistic: whatever your final decisions, there are going to be compromises.
At ThoughtWorks, we believe that building your own Technology Radar can help your work through this decision making process — a living document whose purpose is to assess the risks and rewards of existing and nascent technologies.
The act of creating your Technology Radar necessitates getting a diverse group together from across your organization and having conversations about technology. And these conversations frequently turn up things that you would otherwise miss. You might get to find out about really useful tools that are being used in pockets of the business. Maybe it’ll enable you to uncover problems in your stack that you’d not picked up on. If you want to understand what languages you should support, it can be a great start.
