> 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.

it’s not always a safe assumption.

planned a full rewrite of a product at last company. i knew things were fucked 3 months in. i started really planning the rewrite 1.5 years in.

that year taught me just how fucked it was: bugs galore, race conditions, crashing frontend, testing in customer environments, data loss, rolled their own security (users from any group could login to any other instance).

previous big brained devs really fucked it and there wasn’t much of anything to show for it.

i fixed a bunch of it. but it still needed a rewrite because they had built the wrong thing. which was the bigger issue i realised 3 months in.

> 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.