It depends. What are you doing? What are the constraints? What is the problem? Do you need innovation? Do you need plumbing? Can you lift your eyes and see t

It depends. What are you doing? What are the constraints? What is the problem? Do you need innovation? Do you need plumbing? Can you lift your eyes and see the value in a radically new way? Does it look like what you are already doing, or does a beginner's mind really suggest a new approach? The author sounds like a crabby old guy who doesn't want to change. Probably an artifact of the topic. But it *is* a real problem- people get locked into fancy-chasing. This introduces risk into the project delivery: team based (knowledge) and tech (not adequately debugged). I've worked at length in "fancy" languages and some of the fancy tech. My conclusion is you have a limited amount of investment you can do. Some of this is team based (language learning, keeping the employees happy), some is in product, some is in tech stack (FlashyFancypants DB and SparklePants.JS). Good tech leadership includes picking out what to take risks on, judging appropriate ROI. Note this holds true for open source, not just business projects! I work in a Clojure shop, so I interact with the rewards and risks of this strategy right now. My last team/company, we chose Go for the team language. It wasn't as unilaterally good as some might hope. Nor was it as unilaterally as bad! It was just another language.