[Comment removed by author]
This is a topic full of nuance, tough choices, and exceedingly fine judgement.
It’s disappointing to me that instead of realizing the deep truth in this, the popular elements of the software industry prefer to turn “rules of thumb” into “rules”.
Sort of, I guess?
I find this to be somewhat true, but mantras like “Evolution is easy, creation is hard” don’t square with my experience. So much advice tends to conflict with other advice that I can’t get behind these kinds of simplifications any more. I guess I used to, when I knew a lot less. ;)
Here’s a near truism in my career that conflicts with the OP’s opinion: plan to throw one away, since you will anyway. Brooks' observation has held fast in my projects, as much as the teams I’ve been on have tried to fight it. Sometimes we found out that a fundamental design decision was poor and no longer worked and the easiest solution was to hard cut over to something new. Other times it was a large-ish component that needed to be ditched.
Is that rewriting? Yes. Is that evolution? Also yes. It’s not simple at all, as much as I wish it was.
Thought: Rewrites are bankruptcy for technical debt. (Be glad we don’t have technical debtor’s prisons or technical peonage…)