[thebeardisred]

Start by quantifying what the cost of acquisition is for more developers with said specialization and if that business use case is making you money.

As an engineering leader I have witnessed that oftentimes folks confuse "neat", "cool", and actual business use cases/needs.

[noop_joe]

I guess what I'm wondering is more about the opposite of the "cool/neat" where orgs either prohibit development in non-standard langs (and that was good/bad) or allow development in non-standard langs (and that was good/bad).

What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?

[simonw]

Introducing a new technology - a new language, or new database (like MongoDB), or a new framework is a VERY expensive proposition.

You need to solve all of the following:

- Deployment. How will you run the new thing in production (and QA and staging)

- Upgrades. How will you upgrade to new versions in the future? Who will be responsible for that?

- For databases, backups. How will you backup data? How will you make those backups available for things like data warehouse reporting or replication to teat environments?

- Monitoring. How will you monitor systems built with the new technology, handle alerts etc? How will logging work?

- Profiling and debugging: what tools will you use for this, particularly in production?

- Testing: how will you run the new tech in your CI environments, and your local development environments?

- Development environments: how will you ensure all of your engineers can productively develop with the new platform?

- Expertise and education: who on your team will be the experts to help support the new tech and onboard your other engineers?

- Standards: what common patterns, idioms, styleguides etc will you adopt? Who will make decisions about these, and how will they be enforced?

A productive engineering environment should have widespread, well understood answers to each of these questions for every technology in their stack. The smaller the "approved stack" the easier it is to do that.

As a result of all of this, I think the criteria for introducing something new is to ask if the cost of all of this is justified by the expected improvement provided by the new tool.

That usually means it needs to either make some feature posible that was impossible without it, or it needs to provide a multiple productivity improvement - not just a 1.5x, probably a 3x or higher.

[pixl97]

Also for any larger company: Security, compliance, and legal.

[TheCleric]

At my job we have a set of pre-approved languages and frameworks. If you want to do something outside of it we have an architecture review board you can pitch your idea to, but you better have a good explanation why the existing tools don’t solve the problem and why your suggestion does.