I find the argument against rewriting to be like the DRY principle: an oft-misapplied rule of thumb causing much of the unwarranted complexity in software around us.
Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.
The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.
> Truth is, the cost of “just rewrite it” is as large as your unit of software architecture.
Often, you pick "just rewrite it" when the complexity of a module seems to have grown too high and refactoring to reduce complexity or to hit new objectives seems difficult.
The problem is, a lot of that complexity there may be necessary because of subtlety. Or, we may not do all that much better the next time around.
There's a strong bias in software engineering in particular to underestimate inherent difficulties and overestimate our own capabilities. Sometimes a rewrite is a win, but this bias causes us to select rewrites in times when it ends up not being son.
The problem could be one level up though. It's not just the implementation of a part that's incomprehensible but the design/architecture of how some of the parts interact.
Truth is, the cost of “just rewrite it” is as large as your unit of software architecture. Prefer loosely coupled, cohesive small parts and rewriting to accommodate changed requirements becomes preferable to the alternatives that tack on complexity as landscape evolves.
The world and our model of it both evolve all the time; the current version is not a work of an idiot but a necessary step towards a better solution and a lesson.