My take tends to be not that 'innovation' is bad, but that there are a couple of risks:
- The weaknesses of new tech may not be fully understood. A lot of new tech solves existing problems, while re-surfacing problems that the old tech solved. Everyone thinks it's great until they've used it for a bit longer, and run into those issues.
- New tech runs a higher risk of disappearing/becoming unsupported. If you plan to support your product for a long time, that's a valid risk factor.
For myself, I'm wary of having very new tech as a fundamental underpinning of any piece of work I need to stick around. I'll likely adopt frameworks or database systems cautiously, unless their superiority is overwhelmingly obvious. On the other hand, I'd be a lot more willing to take risks on a simple library.
With a smaller, simpler piece of tech, it's easier to replace if something goes awry, and it's easier to evaluate in its totality prior to taking the risk.
It's not only that, it's also that if you have two languages in your codebase you now need two ways to deploy, two types of application servers, two types of testing frameworks/QA setups etc. If having the two languages means you can create a product only marginally faster/better then it is not worth all of that overhead. As mentioned in the article, there are places where the cost becomes worth it, for instance faceted searching is done in Java via Solr at Etsy. But for the most part fitting your problem into the existing infrastructure is a lot better for the organization than bringing in the perfect technology.
I agree with this. That being said, the author of the post seems to knock 'the right tool for the job', but I recently built two scrapers: one that scrapes an API (one time thing) and one that scrapes some websites (will probably be used once a month). The API one runs on PHP and auto-refreshes with a <meta> tag -- boring, but it works.
The one that scrapes websites I did with Node since some sites are multi-steps and the latency of a single scrape, plus the database latency could've turned this into a multi-week run with PHP
- The weaknesses of new tech may not be fully understood. A lot of new tech solves existing problems, while re-surfacing problems that the old tech solved. Everyone thinks it's great until they've used it for a bit longer, and run into those issues. - New tech runs a higher risk of disappearing/becoming unsupported. If you plan to support your product for a long time, that's a valid risk factor.
For myself, I'm wary of having very new tech as a fundamental underpinning of any piece of work I need to stick around. I'll likely adopt frameworks or database systems cautiously, unless their superiority is overwhelmingly obvious. On the other hand, I'd be a lot more willing to take risks on a simple library.
With a smaller, simpler piece of tech, it's easier to replace if something goes awry, and it's easier to evaluate in its totality prior to taking the risk.