Not necessarily. I have seen it plenty of times where a new contributor/manager comes in, declares all existing code is crap and needs to be rewritten to their favorite language/framework/cloud provider.

A lot of rewrites could be avoided if people spent some time to actually understand what was done before. It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.

[delayed]

> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.

Amen! Code is never written in a vacuum. Code is never shaped only by engineering but by business and organizational compromises as well. I hate those guys who declare we absolutely must do sweeping changes to the codebase/architecture so that we are in line with the latest best practices after spending an hour with the codebase. As if the guys who spent the last 3+ years staring and building on said codebase didn't know any better (unless of course you were hired specifically because you ought to know better!).

> It’s a pretty safe assumption that the people who worked on the codebase before were as smart as you.

The motivations and goals back then could have been different, specially in the case of MVPs

A friend of mine is migrating the company's IaC to TS as we speak because a new manager who recently joined the company decided to do it with no good reason.