Do you ever get scared when developers come back from conferences? I do.
How many times have you’ve had a developer come back from a conference and say, “We should use framework X to build this?”
Recent examples would be, “We should make this into microservices” or “We should use Kubernetes”, or “We should write this new front-end in React.”
There’s a lot to unpack behind this, and I’ve been a part of numerous projects where this was necessary, and even more projects where this torpedoed any chance we had to meeting the expected business outcomes.
Corey Quinn, author of Last Week In AWS, speaks of this phenomena in his talk “Come Scale Away with Me: Solving for problems you don’t have” and its often negative effect on development teams and businesses.
Adopting new frameworks can be critical to the longevity of a business’s software, but those times are few, and the inflection points are often telegraphed (Microsoft has indicated all new development should target .NET 5 (rebrand of .NET Core), so if your business is running on ASP.NET 4.x, you’ll have several years of support ahead of you, but you should start considering moving off of ASP.NET to ASP.NET Core).
Framework changes are akin to tearing down and rebuilding a building. It may be necessary, but is a large capital expenditure and should taken with the same seriousness that building a new office building would be.