When Not to Switch a Programming Language

At one point in almost every developer's career, there is work to be done with an "inherited" project. What this means is you are handed the responsibility of maintaining, improving, and adding features to a project that had many, many decisions and collaborations cooked into it. 

I will be talking about one aspect of this, one which keeps me scratching my bald head: When should I choose to use a different programming language? 

Or rather, when should I not?

Switching Languages Checklist

Though the answer to this question is quite subjective, I think it's helpful to first ask yourself one additional question here: Will changing languages actually help solve my problems? 

What follows is a quick checklist that may come in handy when making this decision. For every point below, a check is made to see if the new language "beats" the old one:

• Programmer experience

  • Ease of learning

  • Tools

  • Maintenance

  • Joy of programming

• Language maturity, domain usages and community

• Business users perspective

• Company perspective

  • Finding new hiries with knowledge in that language

  • Cost of switching 

    • Financial costs

    • Deliverable costs

    • Licenses

Programmer experience

Ease of learning

How long does it take to get comfortable with the language's syntax and thinking patterns (for example Object Oriented vs Functional)? But perhaps more importantly, how long before you are adept at building something quickly while also being aware of the pitfalls and language tweaks?

Tools

Tools start with a decent IDE and end with a decent set of libraries and software helping the development process. So what we are looking at here is not just libraries you can import into your project (and how well they are maintained); nowadays it has to do with how well the language plays with containerization and cloud technologies, with CI/CD etc.. (granted these are not language dependant, but the tooling around them is).

Maintenance

This point goes hand in hand with ease of learning and tools, which is why I placed it third. If the first two points are problematic, maintenance is going to be difficult, especially if your new language breaks compatibility and causes issues with related frameworks and tools.

Joy of programming

This point is subjective, and the reasons are many, but it is an important point from a developer's perspective. 

Language maturity, domain usages, and community

A language is considered mature (in my book) when it has at least a few GA releases and has been tested for a few years in the market, preferrably by the big players. Bonus points go of course to a language supported by big companies and open source communities. 

Now, not every language is suitable to all business domains, even if it has available tools filling that gap; one must be careful with stepping into marketing campaigns and the "next big thing" path. 

Sometimes you are forced to use a certain language for a specific domain or tooling. For example, data scientists and analysts nowadays are typically Python and R users. 

Business users perspective

As with everything related to IT and services, big tech decisions must be met with very solid reasons to clarify risky moves. When it comes to business users (whether internal or customers), the questions to answer are "Why?" and "What will it cost us?"

At this level, many points if checked can be brought forward, for example licensing, support, domain usage, and ease of hiring new people at a reasonable cost.

Company perspective

Finding new hires with knowledge in that language

How many times have you heard the story of the project having an expert in the language and when that expert left the company, the project fell apart?

From a company perspective, it is very important to keep the business alive and not have single points of failure or the concept of irreplaceable talents; one point to cover here is the tech stack this company employs as well as how well the domain knowledge is spread around.

Another negative point coming from a new language or a "not so mainstream" language is that finding quality talents is hard, and when you do find them, there is hardly anyone to assert that they are as good as they claim to be, plus the costs of bringing unicorn experts is very high (salary wise at least).

Cost of switching 

Imagine as a manager you were able to build a team of developers being comfortable enough in the "new" language, but how long will this take? How much time and deliverables delays will it cost you? How fast can you get new hiries to become productive with the new language stack? What about licenses? How much reliable open source software can you use, and how much are you willing to invest in licensed paid software and tools?

Conclusion

To conclude this article, I would like to add a point. In certain cases it helps; in others it does not:

Whenever a decision is made and a switch is to happen, institute a trial period, do some POCs, evaluate, and go back to the drawing board if necessary. It is always cheaper to stop early than to get stuck too late.