He didn’t elaborate but I agree with him. I’ve seen too many examples of junior devs having to work on some small feature or enhancement, and their idea becomes

He didn’t elaborate but I agree with him. I’ve seen too many examples of junior devs having to work on some small feature or enhancement, and their idea becomes rewriting the entire code base in whatever new framework of the month happens to be for the time. Yes there are plenty of reasons to adopt new technology, but you have to balance the pros and cons with keeping your business running and most importantly not disrupting your customers. At the end of the day, honestly, how many frameworks do you need to build webpages? And 95%+ certainly are not operating at a Google or Amazon scale. On a side note, I recently saw a dev spend a few days wrestling with dependency issues - he was trying to wire in Spring into a Java application and running into configuration issues with decorators. At the end of the day, this was a tiny, tiny application that periodically ingests messages from a topic and forwards their payload to an email service. These are 5-10 messages a day and the emails that are generated go to internal business customers as a courtesy and not less of a mission critical notification. It’s worth thinking about what was the business value vs the cost? The take away isn’t that you should never use new technology - rather, understand that new technology or change in general comes at a cost. Your job is to balance that cost considering several factors - code quality (cost of time spent), flexibility and extensibility, features (the stuff valuable to whatever function responsible for your pay check), cost of on going support and maintenance (operational load). Disregarding those factors and over indexing on latest and greatest is usually the wrong approach.