One of the recurring themes of any technology discussion is programming language. It doesn’t take much effort to find blog posts with dramatic headlines (and even more dramatic comments) about how shipping a new project with Haskell or Clojure or Elm improved someones job, marriage, and life. These success stories are posted by raving fans that have nothing but the best to say about their language of choice. A common thread running through these posts is that they are typically tied to building out new, greenfield projects. I can’t help but wonder. After the honeymoon of building a new project with a new programming language, what happens next? Is it all bubble gum and roses?
Sadly, it doesn’t matter how suited to the job a language is, how much fun it is to program in, or how much you learn along the way. What matters the most is if the company you work for can support it. Engineers move on, there are — believe it or not — lean times, and after a few years there is no one left who can support the new esoteric system. Once the application is in production, how do you support it? Who is going to be on call?
Can’t you solve this problem by hiring? Not really. First you need to either find someone with the appropriate skill set or train someone in the skills. Both of these cost time and money. Second, what is the new hire going to do? They will be tasked with a part-time responsibility of maintaining a legacy system written in an esoteric language, while everyone else in the organization is working in something else. And they will be the 24/7 on-call support person. You can help with the on-call situation by hiring an additional two or three people to help support the service. Assuming you need three engineers to maintain a healthy on-call schedule, at roughly $200K per engineer, you are going to be spending $600K a year on this service. Does this new programming language save you that much money every year over using the language everyone else in the organization knows? As a manager or technology lead, what do you do? Keep trying to hire? Keep spending $600K year on a programming language with no discernible business impact? No. You design it out of the system.
A case study. We had an internal development team working on a new documentation portal and they chose to use Elm for the frontend when everyone else was using Dart and JavaScript. The team was able to get the basics up and running quickly, and man they were having fun. But the service became increasingly difficult to manage as product requirements expanded beyond the strengths of the Elm ecosystem’s core competencies. Shortly after, the core development team left to pursue other opportunities.
At first we tried to train existing engineers on Elm. That doesn’t work. Not because Elm is bad, but because people don’t want to change the direction of their career just to support someone else’s legacy project. A second option is to hire at least two, preferably three Elm engineers. This is harder than it sounds. Not all engineers are excited about learning esoteric languages, and these new engineers you hire will be quickly wondering about their career development prospects if they are tied to maintaining the only legacy system written in Elm while everyone else is working on something else.
In the end, instead of trying to maintain the system it was scrapped and rewritten in the common frontend language the rest of the organization uses. Rewrites are a difficult decision for well-known reasons, but ultimately it was the correct choice.
The thesis of this post is that you need to choose a programming language that your organization can support. A natural corollary is that if you want to introduce a new programming language to a company, it is your responsibility to convince the business of the benefit of the language. You need to generate organizational support for the language before you go ahead and start using it. This can be difficult, it can be uncomfortable, and you could be told no. But without that organizational support, your new service is dead in the water.
The most important criteria for choosing a programming language is choosing something your organization can support.