The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."

I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.

Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)

A perennial insight which has been articulated many times before. This feels like one of those stages all engineers pass through at some point in their growth journey. Chesterton's Fence and all that (or Joel Spolsky's "never do full rewrites" advice).

This rings so very true. Have been in the software business for too many decades and having inherited other people's code many many times, there is always the decision about what to do going forward. Leave it running, refactor it gently or rip and replace. Each has it's own set of traps that need to be carefully considered.

> I barely knew CakePHP, so every file looked wrong to me. I knew Laravel, and I loved working in it. So on my own time, unasked, I ported the thing piece by piece, swapping in Illuminate packages until the old framework was gone.

Title is somewhat clickbaity, because these actions are not what people are going to think of when they think of a rewrite in a corporate environment.

By the way, I was an early employee at Amazon.com and the website’s rendering engine was rewritten three times, each time unlocking a new level of productivity without which the site (as well as the velocity of teams) would have slowed to a crawl, and the company would have probably died.

Is this news to anybody? Feels like I should just point AI and several “foundations of software engineering” and have it churn out blog posts for each chapter.

good rewrites are good. bad rewrites are bad.

you’ll only find out which kind of rewrite you’re doing once you start it.

serving the engineer _does_ serve the business, ultimately.

Engineer: but business is not my problem.

> For a few weeks one summer I woke at 4am to rewrite code my employer had already paid someone to write.

I mean, if you do it at 4am, you are sleep deprived by the day two and thus unable to stop yourself from something stupid.