At a small scale, pick the smallest set of boring technologies possible and be strict about using them. Introducing a new technology should only be done if it gives a sizable advantage that can't be had with your existing set. https://boringtechnology.club/

As you get larger (> 50 engineers in my opinion) you may need to switch things up a bit. I really like the "golden path" methodology described by Charity Majors: https://charity.wtf/2018/12/02/software-sprawl-the-golden-pa...

Short version: pick a set of tools that are fully supported by the organization: projects that use them get backups and deployment and testing and ops and development environments all provided by default.

Teams can stray from that golden path, but they'll need to solve that operational stuff themselves.

UPDATE: I just read https://developer.app/expectations/code-neutral/ and I mostly disagree with it: allowing developers to mix and match any langauges and frameworks they feel like is a huge competitive disadvantage and will greatly damage your ability to maintain software and build features productively over time.

The exception is editors and personal development tools - developers should be able to use whatever works best for them there because it has no impact on other developers - my work in unaffected by your decision to use Emacs instead of VS Code.

But don't make your Python programmers on a tiny team have to fix bugs in a Ruby app because some other developer liked Ruby better!

Letting languages be a free for all is a terrible decision for an org of any size.

1. The more languages and frameworks, the more things need to be updated. The number of security upgrades you find yourself doing scales linearly with the number of runtimes you support.

2. If you can't share business logic, you're wasting time. Gluing two microservices together because the logic you need is in another codebase is infinitely more complex than just importing/copying/submoduling what you need.

3. You're not gonna support all those languages forever. Maybe two will survive. The champions of whatever one off project you have will leave, and that code will languish. You will pay the cost of rewriting that code.

4. There's really no issue with "the right tool for the job." All the languages can do all the things if you wield them correctly. The first version of Uber was written in PHP. There's no strategic advantage to picking a language for one specific project: pick your languages to support the needs of all your future projects.

5. Your greatest bottleneck is going to be people. Hiring and keeping good people is and will always be the hardest task you encounter. If you rush it, you get bad people. You simply cannot hire enough people who are either polyglots or of such quantity that you can dedicate them to each one off project in its own special language.

6. You will eventually need to start scanning for security issues. Multiply the complexity of that by the number of languages and frameworks you use. Explain to your general counsel and CFO why is so slow and costly to do an audit.

Unless the main set of languages you have are totally unable to solve the new usecase, its almost certainly going to land on the tech debt side of things. This is a new build chain, set of dependencies, development tools, developer skillset, etc. we are talking about here - not small stuff.

Also to get common libs (e.g. middleware, API definitions) going will be much harder.

The real reason new languages come up in discussion is because of bored developers - that has been my experience at least. And I don't exclude myself from that, it is a major factor in me looking for new work. Now assuming that cynical theory is true, there is an argument to introduce cool stuff to retain good developers - with the understanding that you are shooting yourself in the foot a little bit.

I've wondered about the possibility of allowing a prototype in a "cool" language or framework, with an understanding that it must be replaced soon after by a stable refactor in the existing language set. I think that would appeal to people who want to try something new as well as people who enjoy refactoring, and there would be a kind of extreme programming motivation to the business. I've never tried to get this kind of thing going though.

I've worked at several companies that have used Hack Days as that release valve, which has worked really well.

Once or twice a year have a 2-3 day break where engineers can build prototypes using any technology they like. Ideas that look good can get turned into production projects, sometimes (but not always) rewritten in a supported stack.

I wrote about how multiple languages cost us a lot of time at a previous place

https://zoenolan.org/2022/09/language-choices/

This means now, I have a high bar for choosing something non-standard . It is not just writing the code but all the support, bug fixing, deployment and maintenance. Not to mention being able to hire with those skills

Unless you have a really good reason to, stick to a few programming languages.

Hypothetically let's say F# Guru gets hired. They're the only ones who really knows it. They program a key system in it, then quit.

Who maintains all this F# code.

Agreed - I worked for a company that had no restrictions so there was Java, C#, C++, Python, JavaScript, TypeScript, CoffeeScript, Go, Ruby, Scala, Lua for various different bits and pieces (as well as some more esoteric stuff like a niche database that there very few developers for). I think things kind of worked because the different choices were restricted to very siloed teams but... hardly ideal.

Handle proposing a new language or framework the same as any other proposal: figure out the benefits and drawbacks, and decide if the former outweigh the latter.

Adding a new language or framework to an existing organization has big drawbacks: it requires developers to learn it, adds complexity overhead, and if the project using it integrates with any other projects, well, integration between most languages and frameworks isn't very good. If the organization is already using several languages and frameworks, presumably they cover a wide-range of use-cases, so they're less likely to encounter a new use-case that only a new language or framework solves.

But I'd strongly suggest not to implement a fixed "company will use N languages and M frameworks max", because it depends on the situation. It's similar to enforcing strict coding conventions (e.g. "variable names should be between N and M characters", "functions should be under N LOC", etc.). Sometimes there is a good reason to write unconventional code, and similarly, sometimes there is a good reason to add a new language, no matter how high the number of already-used languages is.

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.

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?

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.

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

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.

Unless your company is large I think it makes perfect sense to limit the languages and frameworks you are allowed to use. For example, we use PHP and Vue at my company, if someone came in and said “we should use React/Angular” I’d seriously reconsider that hire and shut down that insanity. Mostly because there isn’t really anything we care about that can be significantly better in either of those frameworks. The same goes for PHP, we do have a few low-level C programs in our stack but by and large PHP is the main workhorse.

We have best practices, we have code examples, we have libraries all written in these languages/frameworks and it would take a _lot_ to consider leaving that behind for something new and shiny. Most importantly we have experience and expertise in these languages/frameworks, the improvement would have to be massive to consider retraining people.

Often there are hyper-specific examples where X language can do Y thing better than PHP but at the end of the day I’ll take a slower process in PHP over a different language because anyone on my teams can work in PHP whereas it’s going to be a small majority (or 1 person) who can work in the different language.

Put another way I’ll take a homogenous less than perfect (perfect = fastest/best language for each job) codebase over an unmaintainable Frankenstein codebase that falls apart when the person who wrote a certain component (and is the only one that understands it) leaves the company.

It’s the same reason I hate “clever” code. I’ll take 10 lines of easy to read/grok/change code over a one-liner every day of the week.

I’d probably live on an 80/20 rule just to harbour innovation. I really believe you can only innovate and create something novel by doing different to everyone else.

So all core tech uses a consistent language or framework eg

- Frontend: Typescript/React/Next

- Backend: C#/.NET or Python, Go

But people can go wild with things like developer tooling or non-core products and experiment. And I mean experiment:

- Try new frameworks, new languages, new paradigms, new targets, new platforms.

Let your devs build and experiment with chrome extensions, flutter apps, Swift games, Kotlin VPNs, Lisp DSLs, python TUIs, ascii games, anything just something different from normal work

If you just do bread and butter dev work 100% of the time and stay consistent with that, you will become a bread and butter shop, and you will stay a bread and butter dev. Period.

Sometimes life needs a bit of spice

At work we use Typescript, React, Next, backends are Node, Python, C# as the defaults.

But I want to build browser extensions for them in React to extend their online SQL editors. And I want to build TUIs with Go to monitor containers and orchestrate project starts. Maybe I’ll write a data processing command line tool in Lisp. I reckon go wild with developer tooling.

I had a client that enforced writing every customer facing software in C++14. In 2024 they suddenly need to support various web technologies and modern web infrastructure. They still rely on their language limitations and don’t get stuff done any longer.

I advised to use Go and most developers were interested and even enthusiastic about it. We proved Go introduction by using it for simulators and testing. But finally the tech lead said "we will never ship anything different than C++ written applications".

My current client also works in embedded tech, but I proposed a polyglot approach and architecture. We ship apps in Go, Rust, C, C++ and even Fortran. Any developer can pick up any language as long as it compiles to Armhf. No one has a problem reading and at least maintaining any code.

There should only be technical limitations and constraints to force down your fellow developers.

Frameworks are a different topic. Web frameworks come and go, and most Angular shops I know became desperate legacy plumbing shops. Only use frameworks that you can replace easily or are willing and capable to maintain yourself.

Very typical and probably the most important takeaway: these things are almost never decided by technical merit.

Almost any organization, once it reaches a certain size, ends up thinking about standardizing on languages and technologies, and put in place certain systems to support the preferred choices and discourage others.

Whenever the subject is revisited, it tends to end up as a political fight at the management level, and technical folks don't have much say. Even when a company does have set standards, if the project is important enough to be visible at a high enough level, the technology choice can go against the standards.

In one case I'm aware of, a shop that was heavily Microsoft/C#/TS/Azure chose Go and K8S for a high-visibility project, despite almost no one in the company knowing those technologies, and the few who did could not be pulled away from their existing work.

Absolutely; the issue has to do with the "Cognitive Load" imposed on the programmer. Standardizing on a small set of languages/frameworks(ideally one) also has the advantage that developers can better communicate/interact with each other using a common language thus enabling better overall productivity.

The Cognitive Load Theory in Software Development - https://thevaluable.dev/cognitive-load-theory-software-devel...

Cognitive Loads in Programming - https://rpeszek.github.io/posts/2022-08-30-code-cognitiveloa...

Cognitive load - https://en.wikipedia.org/wiki/Cognitive_load

I agree with the other comments that are basically saying to be conservative about adding to your toolbox. Additionally, I recommend using technologies with existing heavy investment from the industry. For example, anything on the top of this list is a safe choice of language in general: https://survey.stackoverflow.co/2023/#most-popular-technolog... . This reduces risks from having to assume maintenance burden, hiring difficulties, finding support, integration with other technology, and more. Adopting some tool that is later abandoned is a frequent source of pain for small companies. Of course, there may be good reasons to stray from this guideline in some cases.

IMHO, it's pretty useful to have some consistency across a large organization. That way lessons learned can be applied broadly, and you can pull in people from elsewhere to work on hard problems, etc.

It doesn't necessarily need to be one way to do things worldwide, but you probably don't need to support 5 server operating systems, 7 http servers, and 35 languages in production.

Yes for production pieces that Must Work Always, but your devs need freedom to experiment when designing new tools, so your list of approved technologies had better be flexible, or you’ll have a different kind of maintenance problem down the line. As well as problems retaining the talent you already have.

Yes. You should use the lowest number of "technologies" possible. Also, I'd say that frameworks are harder to learn than languages, so they should be adopted with the same level of caution.

Probably not unless there is a really good reason.

If you have a problem that can be fixed by restricting languages, you don’t need to ask hacker news.

If you don’t have a problem that it solves, probably don’t do it.