0. https://developer.app/expectations/code-neutral/
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!
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.
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.
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.
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
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.
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.
As an engineering leader I have witnessed that oftentimes folks confuse "neat", "cool", and actual business use cases/needs.
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?
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.
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.
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 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.
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.
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
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.
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.
