(2) Multiplication of surface area for things like security bugs... now you have five different stacks to keep track of security updates for instead of just one.
(3) Multiplication of deployment resources-- now you need multiple VMs, maybe multiple instances with different stacks to run them on, etc.
(4) Developers can't pinch-hit for each other unless they know every damn stack in the world.
(5) If you sell, God help whoever has to support that stuff in your new organization.
(5) If you sell, God help whoever has to support that stuff in your new organization.
It would be interesting to know if an acquisition fell through because due diligence revealed something like this and the purchasing entity didn't want to deal with that mess or it conflicted with their culture.
Absolutely not - no it manager worth their salt will pass up the opportunity to say - well we can do it but we will need more cash - we have to hire a ruby team a node team a ...
In the 1970s, the US DoD had what one could parallel to SOA. They had hundreds of languages; they'd start a new project and with it came a new programming language, stack and toolset. They created the High Order Language Working Group which worked on a document of requirements for one language to rule them all, the Steelman. A competition was had to which 4 colorful languages were entered. The winner, Green, became Ada which coincidentally has just wrapped it it's latest language revision process at ISO. Much of the Steelman focused on maintenance, reliability, readability and other traits that make for good software that will last. It is a good thing take that step back and make sure we are programming up to her level.
Yes. The more different languages (and frameworks) someone has to know, the harder it is to hire them. If you hire people who only know the language of one small part of your system, they can't help out on other parts during emergencies and there will be difficulties adding new parts (which language do you use, or which existing part do you steal developers from). If you hire people who know one language and train them in the rest, the more languages there are the more that training will cost.
And it's rather a good thing, no? I mean, for me, as a developer who happens to know at least a dozen of languages quite well and has a basic grasp on a dozen more, I like it that way. Namely, I like being a harder to find good with limited supply, this means that I will be paid more.
Otherwise what would be the point of learning all these languages, frameworks, libs and environments? Of course the learning experience can "make you a better developer", but is it supposed to be only that?
