How Teams Choose Language
How Teams Choose Language
You wouldn't use a hammer to unscrew a screw, or use a screwdriver to pound in a nail. So why use an unfit language for your software?
Join the DZone community and get the full member experience.Join For Free
One of the important decisions in developing a program is choice of language. As of now, we probably have hundreds of programming languages and the number is growing. Selecting the optimal programming language is probably the way to go, but sadly that's not what happens in real life. In my experience, the teams tend to choose a programming language for the job without much reasoning.
A Team Member is Excited
We as developers like to explore and learn the new tech. As a result of this, we learn new programming languages and we want to code in that language. The easiest way to do that is to start a new project with the new language. Without much thinking, the developers dive into a rabbit hole with a new programming language and new tooling. The project works great and everybody is happy about it for a while. A bunch of people who were comfortable with the project quit and the code becomes legacy. Now, nobody else knows neither the language nor the tooling, or the developers suddenly understand the language chosen isn't really a good choice for their project. So, they start hacking and making ways to make it better because there's no turning back.
The Senior Engineer's Choice
You start a new project and you pick the language which the senior engineer is comfortable with. S/he wants to code in that language because s/he's comfortable with it and s/he can do code reviews easily. The project starts and you realise it's not getting any better. Maybe the language lacks the functionality or framework support around the project you are developing. So, what do you do? You re-invent the wheel by adding these functionalities. It could have been free if it was in a more appropriate language.
The Mainstream Language
Sometimes, the company heavily invests in a particular language for various reasons and everybody becomes comfortable with it. They hire people who know how to code in that language and the loop goes like that. Therefore, they solve every single problem with the same language and tooling. When they hit a shortcoming of a language, they fix/improve it with interesting approaches. However, they could have avoided the problem by using the legitimate language for each task.
What's the Problem?
Your boss doesn't care about the language. The only thing matters is delivering the project reliable and fast. When you pick the wrong language for the job, you end up doing extra work for the above reasons. So, what happens to delivery? You can deliver neither quickly nor reliably, and your funding may get cut off, or the customer becomes unhappy and no longer wants the product. On the other hand, if your company makes so much money than it doesn't matter, you can probably implement hacks. Maybe implementing the hacks are advantageous over switching to another language.
The Right Tooling Matters
Before starting a new project or adding additional features, we should take some time to think about what's the optimal language or tooling for the project. There are several factors to consider like options for maintenance, the payoff for choosing a candidate language, available frameworks, learning curve, deployment environment, user base and etc. If you carefully compare available languages for the job and decide which language to go for logically, it'll make things easier in the long run.
Teams select a programming language for a given task because of various reasons. Nevertheless, the choice for the language may not really depend on the rational comparisons. Teams may choose a language because somebody in the team likes a new language, a senior member of the team suggests his favourite language, or the company is too deep in some particular language. All in all, right tooling or language matters as the time to market depends on it. Hence, we should better spend some time evaluating languages before starting something new.
Published at DZone with permission of Yusuf Aytaş , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.