upvote
I do "rewrites" for my day job all day every day; with as of late the goal being rewriting critical services to get past scaling plateaus.

Rewrites require an existential-level threat to pursue and should never be taken lightly. They must solve a real verifiable need, backed by real world data. Rewrites for rewrites sake or some lofty or nebulous goal of "better" or "more maintainable" code are doomed to fail and a waste resources.

I've seen the worst of it, from your average monoliths with no separation of concerns to 1000s of lines of self-modifying assembly in dead architectures with no code comments containing critical business logic, etc.

The main rule is to not to bite off more than you can chew, which if I'm being honest you really only learn from fucking up or watching others fuck it up.

reply
They said a Proof of Concept goes to prod. That’s not “rewrite the whole service that’s been built for months”. That’s “I vomitted a neat thing over the weekend” -> now it’s in prod.

Hackathon and overnight oncall fixes ABSOLUTELY should be rewritten or production-hardened, but they very often are not.

reply