Exactly this. Many times just because something is new does not mean that it's better, or even mature enough to use.
I'm both in the business world as well as a developer, here's my experience ...
I was riding the new tech wave as well as a young Tech Jedi. Built a polymer-dart project, put it in production, a year later and polymer actually became 1.0, but not compatible with 0.5. Now to keep that project up to date, we have to spend almost as much as we spent on building it, lots of money down the drain. Python, we were riding the latest and greatest Python 2 libraries, built awesome stuff quickly, two years later and Python upgraded to Python 3, plenty of the libraries we used is no longer supported and we have to do a rewrite to get stuff to work in Python 3 - the initial project costs several million to develop, we haven't made estimates how much it will cost to migrate / rewrite to Python 3, but it still seems like a waste. PHP, we built a giant system in PHP, since PHP doesn't have type safety, we had some random errors in the system that none of the developers could solve, somewhere in the code something that was supposed to be an integer morphed into a string and strange things happen. ExtJS, similar issues, after a year or two, it becomes difficult to support the old system.
Java, so far stuff that we have built 5-7 years ago still runs perfectly, if we need to add features, we simply add the features and stuff continues to work, we've never needed to rewrite anything due to libraries not being supported anymore, porting things to the latest versions of libraries usually works without any tinkering, in the cases where it doesn't, the older versions from 10 years ago of that library is still available and we can stay in business.
For the software we've been building in the last 1.5 years, we've been using Spring + Java heavily in the backend and we've made a bet on Dart for the frontend seeing as Google is already using it internally. The result is we have rock-solid backends with which we can easily handle 100+ requests per second, scaling is easy due to the middleware we've chosen (something which was developed 20 years ago), plenty of developers available who can work on it, if we run into a problem, a quick post on StackOverflow usually gets us an answer within 10 minutes, the number of options to deploy on is big, we have docker support and can run it on just about any kind of server. Dart so far has helped us get frontends out very quickly, we're hoping that Dart will give us the same kind of stability with backwards compatibility we're getting with Java which means we can spend resources on marketing and new features, rather than rewriting stuff every 2 years.
I read nice blog post about this topic a few days ago.
What it basicly said was that there are two types of developers in every company: Conservative programmers which care more about WHAT are problems they need to solve and on the other site Inovators which care more about HOW the problem is solved. And you need both types in your team. The author recommends to use new technology if:
- you know it from some other project
- you want to do something that is not possible with your current technology
- you can find people who understand this new technology and you can't find people who understand the old one
- you will be more productive even if you count in the time for learning it
The article can be found here (but is written in czech): knesl.com/articles/view/co-budujete-v-cem-b..
As for my personal opinion newer and trendy does not always mean better. For example I do not like the new Atom editor (written in Coffeescript/JS) from GitHub. I find it really slow and laggy especially when I compare it to Sublime Text 3 (written in C++, plugins in Python), which I use for daily work.
What I saw in my short time as developer is that often people who are sitting in the positions to choose the technologies don't know anything about these things.
Another reason is that companies often already have a working system and it is a question of money, if they change their whole architecture, so that they have a... working system again. An accountant, who gives the money wouldn't see the reason here.
Or, they simply don't have the capacity and the knowledge. How do you want to change the system if nobody knows how?
I'm in the position to talk to CIOs and CTOs of MNCs quite a bit, and my observation is that they are primarily thinking about risk to the organization. They view risk through a number of lenses: - delivery risk (does this speed up development? does it introduce quality concerns?) - security risk (is this a proven technology? who's looking at it for security? how quickly are issues resolved?) - people risk (do I have enough resources to use this technology at the scale that I will need to use it? will people leave if they are forced to use it / if they cannot use it?) - integration risk (how does this fit into the enterprise's architecture? is it interoperable with what the organization currently uses?)
There are probably 5 or 6 more different types of risk, but those are the ones that are top of mind. So that said, I don't think MNCs are "avoiding" new technologies, I think they are adopting those technologies at a different speeds. Companies like Facebook, Google, etc. have different risk profiles than, say, a manufacturing company in the Fortune 500. I believe it was Gartner (a company that issues reports on technologies and trends in the enterprise IT space) that created an adoption curve that talks about "Pioneers", "Fast Followers", "Slow Followers", and "Laggards". Big MNCs are spread across the spectrum, but generally fall into the last three categories - they wait to see what will emerge as standards and, where they can find resources who know the technologies.
Two caveats to this: One - Many MNCs WILL develop on these technologies, just on smaller projects (everything from internal projects to proofs of concepts, etc) where if the application fails or doesn't work, there's no critical impact to the business. Two - other commenters have talked about "corporate inertia" - if it works, why "fix" it? I think the addendum to that is "If it works, and our business requires it to work, should we take the risk of breaking it?"
- When you say 'big' do you mean 'legacy' companies or big in terms of revenue / employees etc? Is BBC big enough? BBC is using nodejs & Go. Ref how bbc uses nodejs & how bbc uses go.
- It takes enormous effort to port legacy applications to anything newer. Unless there is enough justification, nobody wants to touch what is working and bringing in loads of money.
- Nodejs may be newer, it is not yet been proven it is better. Big companies have to think in long term. Will Nodejs survive for another 10 years? Will it scale for 1k concurrent connections? IT departments in these companies have to evaluate on many params. New & shiny is not one of the criteria. Sturdy & stable probably are.