[HN Gopher] Ask HN: Should orgs limit the number of languages/fr...
___________________________________________________________________
Ask HN: Should orgs limit the number of languages/frameworks?
My teammates have been working on a collection of documents [0]
about developer platforms and we've been talking about limits
organizations can impose on acceptable languages and frameworks.
Curious what HN thinks, how do you handle cases when there's an
unused language that might be better suited to a business use-case?
0. https://developer.app/expectations/code-neutral/
Author : noop_joe
Score : 13 points
Date : 2024-06-03 19:40 UTC (3 hours ago)
| thebeardisred wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Also for any larger company: Security, compliance, and
| legal.
| MeetingsBrowser wrote:
| 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.
| simonw wrote:
| 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!
| devdude1337 wrote:
| 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.
| cratermoon wrote:
| 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.
| liampulles wrote:
| 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.
| simonw wrote:
| 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.
| armchairhacker wrote:
| 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.
| zoenolan wrote:
| 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
| 999900000999 wrote:
| 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.
| toast0 wrote:
| 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.
___________________________________________________________________
(page generated 2024-06-03 23:02 UTC)