One Standard Language Versus Team-Chosen Languages
TradeoffPrincipalUpdated
Three hundred backend engineers work across five languages. A platform team of ten maintains build tooling and software development kits (SDKs) for all five, and on-call engineers often can't read the services they get paged for.
Short answer: One Standard Language. Standardize new services on one primary language and approve exceptions case by case, so the shared tooling bill stops multiplying by five.
The Two Options
A
One Standard Language
B
Team-Chosen Languages
Drill This: Your Pick First
The Better Pick
Option A
One Standard Language
Standardize new services on one primary language and approve exceptions case by case, so the shared tooling bill stops multiplying by five. Every extra language needs its own build tooling, SDKs, security patching, and experts, and that cost lands on the platform team and on-call. One language also lets engineers move between teams and read any service during an incident.
When the Other One Wins
Team-Chosen Languages
When a domain has needs the standard language serves poorly, such as data science in Python or low-latency systems in Rust or C++, approve that language for that domain.