DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Five Java Books Beginners and Professionals Should Read
  • JavaFX Goes Mobile
  • WireMock: The Ridiculously Easy Way (For Spring Microservices)
  • 4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
  1. DZone
  2. Popular
  3. Open Source
  4. When Not to Switch a Programming Language

When Not to Switch a Programming Language

When it comes to inherited projects, you may be tempted to change programming languages. But before you do, you should really ask yourself: Will this actually solve my problems?

Nibal Sawaya user avatar by
Nibal Sawaya
·
May. 28, 19 · Opinion
Like (3)
Save
Tweet
Share
7.08K Views

Join the DZone community and get the full member experience.

Join For Free

Image title

This developer's conundrum: "Should I realy change programming languages at this point in the project?"

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.
Open source

Opinions expressed by DZone contributors are their own.

Trending

  • Five Java Books Beginners and Professionals Should Read
  • JavaFX Goes Mobile
  • WireMock: The Ridiculously Easy Way (For Spring Microservices)
  • 4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: