7 ms·

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't

In general language diversity at a company is a big negative. Obviously sometimes there are even bigger negatives that mandate overriding that rule--you aren't going to use Java on the front end or javascript on the backend, that would be madness--but you never want two languages in the same niche. That's a cost with no benefit. If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care.

michaelterryio 8y ago
Erlang excels at being used in mixed-language shops. Erlang is an incredible control plane language.
nojvek 8y ago
Language diversity is a pragmatic balance. Sometimes a language offers superior abstraction or some guarantees that eliminate a whole host of bugs and manual effort. It’s always worth trying a hypothesis in a small spike and reliably proving whether it will scale to the rest of the org and the impact will be worth the effort. But you’re right, there should be one official supported way of doing some kind of thing at a company.
- lightcatcher 8y ago
  I think of it as a trade-off between the tool perfectly designed for the job and the tool that can be used for the job of which I'm already an expert user. As an example, my current team's codebase is Python and C++. When we need to do some basic Linux scripting (check if this file exists, if not send an error email), the two prime candidates are Bash and Python. Bash might be exactly designed for this type of thing, but a lot of the team would need to Google stuff like "bash logical and of two booleans" for Bash where they already know the Python syntax. My current rule of thumb here is "<10 lines of code: use Bash. else use Python". More generally, I often try to err on the side of using the tool I know than the unknown tool that might be perfect for the problem.
jacquesm 8y ago
> or javascript on the backend, that would be madness It seems madness is pretty common.
- Daishiman 8y ago
  It is. Mistakes take a far longer time to be understood than fashion.
- k__ 8y ago
  True. For most projects, it's good enough. Also, I worked for many shops that had a two language policy, one for development speed and one for performance. For example, PHP and C or something. They had many PHP devs and a few C devs and would write anything new in PHP and then later replace the few performance critical parts with C implementations. I thought about doing this with JavaScript and Rust in my projects, but somehow I never got to the point that JavaScript became the bottle-neck.
tomjakubowski 8y ago
You could fire them or you could just help them understand something that they don't. Sheesh.
- deleted 8y ago
  [deleted]
- bradleyjg 8y ago
  Fair. That part was over the top. But I do think employees pushing their own intellectual passions or resume building pursuits over the interests of their employer are pernicious. If it’s out of ignorance, then sure by all means educate.
  - collyw 8y ago
    It's a two way street. Employers always want the most up to date trendy frameworks on their employees CV's. I imagine someone that has been working on a legacy VB6 app for the last few years will struggle to get his CV looked at.
detaro 8y ago
> If you have some developer that wants to write something in a new (for your company) language, [...] you probably want to fire that guy. Now that's > a cost with no benefit.
aiisjustanif 8y ago
Depends. If it's a internal, innersourced, tool for everyone. Have at it, use another language. If it's my critical application, explain why we use only one language for it and don't fire them. We teach, not react.
scarface74 8y ago
We have three approved languages - C#, JavaScript and Python. Of course C# you get all of the advantages of statically typed languages, so for major programs where you wil have multiple developers, it’s the go to language. But for smaller scripts like event based lambdas and scripting type scenarios, C# is overkill. Besides, each piece of AWS functionality is in its own NuGet package as opposed to one package for everything for JavaScript (Node) and Python. JavaScript - our product is web based. Every developer is expected to know JS. So if someone decides to do a simple Microservice or lambda in C# or JS, it’s okay. Whichever they feel like doing, it’s okay. We have another team that does a lot of ETL type processing. I doubt that many people would argue that JS is a better language for it than Python. If you are on that team and need to write something, you can choose whichever of the three languages you wish.
cellularmitosis 8y ago
Some dev: "Hey, I noticed one of our more complex API endpoints had some pretty bad response latency, so I dug into it a bit. It turns out our PHP/Symfony/Doctrine stack was generating over a hundred SQL queries, all of which were being performed sequentially because we don't have a good per-request concurrency story in this tech stack. So I wrote an alternate implementation in Clojure which has a great concurrency story and cut the latency by 75%." lol yeah that guy should totally be fired.
- theamk 8y ago
  If there are no other people who can maintain that stack, maybe (firing is too extreme, I’d just ban the Clojure code in the production) Writing initial version of the code is only a small part of it. Maintaining and enhancing it is much harder. What is the company going to do if the new endpoint went down and the author is on vacation?
  - Silhouette 8y ago
    A lot of these objections depend on context, though. The culture at large organisations taking on large and/or long-running projects is necessarily different to the culture at small organisations that can't afford the same overheads and wouldn't enjoy the advantages of greater redundancy or interchangeability anyway.
  - cellularmitosis 8y ago
    > just ban the Clojure code in the production A dev ran up against the limitations of one platform and solved the problem by choosing a platform which didn't have those limitations. And management responded by banning the new platform. How long do you think that dev is going to stick around in an environment like that? Ultimately this comes down to what sort of environment you want to foster. One approach leads to an environment where devs have lots of freedom, and that creates certain problems. The other approach eventually leads to an environment where even the choice of editor / IDE is dictated, and that creates a different set of problems. I'd favor attracting a bunch of smart folks and give them as much freedom as possible. I'd much rather deal with the kind of problems which that sort of environment creates.
Silhouette 8y ago
If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care. What if it has the potential to be a much better tool for the job than the mainstream options, and your developer thinks it's worth trying it to find out? I've seen this situation with adopting a relatively unusual language for a task that needed particularly high reliability. Yes, it was a concern that only one person currently working in the organisation knew much about it and that it might be harder to hire help if more developers were required later. On the other hand, that software was developed faster than the similar system it was due to supersede, and it had a much lower rate of reported bugs once deployed. Of course you don't want to hire people who intend to pad their resumes with extra buzzwords on your dollar when it has no business benefit, but equally, if you never use tools that aren't chosen from among a small set of mainstream options, you'll never outperform what you can do with mainstream tools.
- pjmlp 8y ago
  Software development is much more than just programming languages, I have seen teams outperform with lousy languages thanks to a great team spirit and understanding of customer needs.
  - Silhouette 8y ago
    For sure. A good craftsman will do good work with any reasonable set of tools. They'll still achieve their best possible results and performance with high quality tools of their own choosing, though.
- bradleyjg 8y ago
  I guess my answer would be that this is the kind of decision that requires being able to see the big picture. Is an individual developer in a position to weigh future recruitment challenges? My remark about firing a person merely wanting to write something in a different language was off base and end up derailing the discussion. But the point I should have made, and stick by, is that this decision is properly made at either the company wide level, or for large companies at the level several rungs up the ladder. It isn't at all, like someone suggested above, equivalent to picking a personal IDE.
ummonk 8y ago
Why would it be madness to us javascript on the backend?
- collyw 8y ago
  Because there are far better languages to choose from.
nathan_long 8y ago
> In general language diversity at a company is a big negative I agree. It really increases the difficulty of understanding the whole system. But it's a negative that has to be considered alongside potential benefits. > If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. I get what you're saying; resume-driven development can ruin your systems. But at some point between "we wrote this new banking system in COBOL" and "every developer who knows COBOL and could maintain our old system is now dead", there needs to be an accepted way to experiment.
teilo 8y ago
My company is an example of this, and in a way that is quite different from that laid out in the article. We actually began with a Python implementation for our integration / API server. But this was well before asyncio and eventlet and kestral. It didn't scale well, and we quickly outgrew it. We implemented its replacement in Elixir, a solution we are still running. It is written by a developer we still have, is well organized, follows proper functional paradigms, and fully leverages OTP/Genserver. It is resilient, and so far as the one two developers we have working in it at present, easy to maintain. We love it. But we also are switching back to Python. The reason is simple: We only have two Elixir developers (really only 1.5), and we have far more work than they can complete. And when something breaks (usually because something changed in the various systems being integrated), we have one guy who can fix it, and get our production queues flowing again. We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. And now that we have asyncio/eventlet/etc., the landscape has drastically changed. In Python, the various teams can create their own worker modules, and do so more efficiently because they know their own workloads far better. Language diversity IS a problem when it impedes development and puts production at risk.
- bcbrown 8y ago
  > We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. Was there any consideration of training up the Python developers on Elixir?
  - teilo 8y ago
    That's the 0.5 Elixir developer. Let's face it: It's easy to become a poor Elixir developer, but those capable of becoming a good Elixir developer such that it's worth the cost of effort to train them, are uncommon. As the CIO, where the buck stops, I learned Elixir well enough to write my own Genserver-like implementation from scratch, and thoroughly enjoyed it. I wanted to be able to understand the code base. But I am still a far better Python developer than I will ever be an Elixir developer. It's all a question of time utilization. Due to the modular nature of our integration, it's relatively easy to move from one platform to the other, one module-at-a-time. And in the end, the cost of getting a new Python-based platform up-and-running far outweighed the cost of trying to retrain Python devs.

michaelterryio 8y ago

Erlang excels at being used in mixed-language shops. Erlang is an incredible control plane language.

nojvek 8y ago

Language diversity is a pragmatic balance. Sometimes a language offers superior abstraction or some guarantees that eliminate a whole host of bugs and manual effort. It’s always worth trying a hypothesis in a small spike and reliably proving whether it will scale to the rest of the org and the impact will be worth the effort. But you’re right, there should be one official supported way of doing some kind of thing at a company.

lightcatcher 8y ago
I think of it as a trade-off between the tool perfectly designed for the job and the tool that can be used for the job of which I'm already an expert user. As an example, my current team's codebase is Python and C++. When we need to do some basic Linux scripting (check if this file exists, if not send an error email), the two prime candidates are Bash and Python. Bash might be exactly designed for this type of thing, but a lot of the team would need to Google stuff like "bash logical and of two booleans" for Bash where they already know the Python syntax. My current rule of thumb here is "<10 lines of code: use Bash. else use Python". More generally, I often try to err on the side of using the tool I know than the unknown tool that might be perfect for the problem.

jacquesm 8y ago

> or javascript on the backend, that would be madness It seems madness is pretty common.

Daishiman 8y ago
It is. Mistakes take a far longer time to be understood than fashion.
k__ 8y ago
True. For most projects, it's good enough. Also, I worked for many shops that had a two language policy, one for development speed and one for performance. For example, PHP and C or something. They had many PHP devs and a few C devs and would write anything new in PHP and then later replace the few performance critical parts with C implementations. I thought about doing this with JavaScript and Rust in my projects, but somehow I never got to the point that JavaScript became the bottle-neck.

tomjakubowski 8y ago

You could fire them or you could just help them understand something that they don't. Sheesh.

deleted 8y ago
[deleted]
bradleyjg 8y ago
Fair. That part was over the top. But I do think employees pushing their own intellectual passions or resume building pursuits over the interests of their employer are pernicious. If it’s out of ignorance, then sure by all means educate.
- collyw 8y ago
  It's a two way street. Employers always want the most up to date trendy frameworks on their employees CV's. I imagine someone that has been working on a legacy VB6 app for the last few years will struggle to get his CV looked at.

detaro 8y ago

> If you have some developer that wants to write something in a new (for your company) language, [...] you probably want to fire that guy. Now that's > a cost with no benefit.

aiisjustanif 8y ago

Depends. If it's a internal, innersourced, tool for everyone. Have at it, use another language. If it's my critical application, explain why we use only one language for it and don't fire them. We teach, not react.

scarface74 8y ago

We have three approved languages - C#, JavaScript and Python. Of course C# you get all of the advantages of statically typed languages, so for major programs where you wil have multiple developers, it’s the go to language. But for smaller scripts like event based lambdas and scripting type scenarios, C# is overkill. Besides, each piece of AWS functionality is in its own NuGet package as opposed to one package for everything for JavaScript (Node) and Python. JavaScript - our product is web based. Every developer is expected to know JS. So if someone decides to do a simple Microservice or lambda in C# or JS, it’s okay. Whichever they feel like doing, it’s okay. We have another team that does a lot of ETL type processing. I doubt that many people would argue that JS is a better language for it than Python. If you are on that team and need to write something, you can choose whichever of the three languages you wish.

cellularmitosis 8y ago

Some dev: "Hey, I noticed one of our more complex API endpoints had some pretty bad response latency, so I dug into it a bit. It turns out our PHP/Symfony/Doctrine stack was generating over a hundred SQL queries, all of which were being performed sequentially because we don't have a good per-request concurrency story in this tech stack. So I wrote an alternate implementation in Clojure which has a great concurrency story and cut the latency by 75%." lol yeah that guy should totally be fired.

theamk 8y ago
If there are no other people who can maintain that stack, maybe (firing is too extreme, I’d just ban the Clojure code in the production) Writing initial version of the code is only a small part of it. Maintaining and enhancing it is much harder. What is the company going to do if the new endpoint went down and the author is on vacation?
- Silhouette 8y ago
  A lot of these objections depend on context, though. The culture at large organisations taking on large and/or long-running projects is necessarily different to the culture at small organisations that can't afford the same overheads and wouldn't enjoy the advantages of greater redundancy or interchangeability anyway.
- cellularmitosis 8y ago
  > just ban the Clojure code in the production A dev ran up against the limitations of one platform and solved the problem by choosing a platform which didn't have those limitations. And management responded by banning the new platform. How long do you think that dev is going to stick around in an environment like that? Ultimately this comes down to what sort of environment you want to foster. One approach leads to an environment where devs have lots of freedom, and that creates certain problems. The other approach eventually leads to an environment where even the choice of editor / IDE is dictated, and that creates a different set of problems. I'd favor attracting a bunch of smart folks and give them as much freedom as possible. I'd much rather deal with the kind of problems which that sort of environment creates.

Silhouette 8y ago

If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. Either he doesn't understand the downsides or he does, but doesn't care. What if it has the potential to be a much better tool for the job than the mainstream options, and your developer thinks it's worth trying it to find out? I've seen this situation with adopting a relatively unusual language for a task that needed particularly high reliability. Yes, it was a concern that only one person currently working in the organisation knew much about it and that it might be harder to hire help if more developers were required later. On the other hand, that software was developed faster than the similar system it was due to supersede, and it had a much lower rate of reported bugs once deployed. Of course you don't want to hire people who intend to pad their resumes with extra buzzwords on your dollar when it has no business benefit, but equally, if you never use tools that aren't chosen from among a small set of mainstream options, you'll never outperform what you can do with mainstream tools.

pjmlp 8y ago
Software development is much more than just programming languages, I have seen teams outperform with lousy languages thanks to a great team spirit and understanding of customer needs.
- Silhouette 8y ago
  For sure. A good craftsman will do good work with any reasonable set of tools. They'll still achieve their best possible results and performance with high quality tools of their own choosing, though.
bradleyjg 8y ago
I guess my answer would be that this is the kind of decision that requires being able to see the big picture. Is an individual developer in a position to weigh future recruitment challenges? My remark about firing a person merely wanting to write something in a different language was off base and end up derailing the discussion. But the point I should have made, and stick by, is that this decision is properly made at either the company wide level, or for large companies at the level several rungs up the ladder. It isn't at all, like someone suggested above, equivalent to picking a personal IDE.

ummonk 8y ago

Why would it be madness to us javascript on the backend?

collyw 8y ago
Because there are far better languages to choose from.

nathan_long 8y ago

> In general language diversity at a company is a big negative I agree. It really increases the difficulty of understanding the whole system. But it's a negative that has to be considered alongside potential benefits. > If you have some developer that wants to write something in a new (for your company) language, or even worse goes off and does so without asking, because he wants to try it out, you probably want to fire that guy. I get what you're saying; resume-driven development can ruin your systems. But at some point between "we wrote this new banking system in COBOL" and "every developer who knows COBOL and could maintain our old system is now dead", there needs to be an accepted way to experiment.

teilo 8y ago

My company is an example of this, and in a way that is quite different from that laid out in the article. We actually began with a Python implementation for our integration / API server. But this was well before asyncio and eventlet and kestral. It didn't scale well, and we quickly outgrew it. We implemented its replacement in Elixir, a solution we are still running. It is written by a developer we still have, is well organized, follows proper functional paradigms, and fully leverages OTP/Genserver. It is resilient, and so far as the one two developers we have working in it at present, easy to maintain. We love it. But we also are switching back to Python. The reason is simple: We only have two Elixir developers (really only 1.5), and we have far more work than they can complete. And when something breaks (usually because something changed in the various systems being integrated), we have one guy who can fix it, and get our production queues flowing again. We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. And now that we have asyncio/eventlet/etc., the landscape has drastically changed. In Python, the various teams can create their own worker modules, and do so more efficiently because they know their own workloads far better. Language diversity IS a problem when it impedes development and puts production at risk.

bcbrown 8y ago
> We have looked for more Elixir developers. They are rare beasts. But we have a lot of Python developers. Was there any consideration of training up the Python developers on Elixir?
- teilo 8y ago
  That's the 0.5 Elixir developer. Let's face it: It's easy to become a poor Elixir developer, but those capable of becoming a good Elixir developer such that it's worth the cost of effort to train them, are uncommon. As the CIO, where the buck stops, I learned Elixir well enough to write my own Genserver-like implementation from scratch, and thoroughly enjoyed it. I wanted to be able to understand the code base. But I am still a far better Python developer than I will ever be an Elixir developer. It's all a question of time utilization. Due to the modular nature of our integration, it's relatively easy to move from one platform to the other, one module-at-a-time. And in the end, the cost of getting a new Python-based platform up-and-running far outweighed the cost of trying to retrain Python devs.