Kent Beck is not talking about rewriting from scratch. He's explaining how to transform software to a better state by taking tiny steps in changing the existing system.
I'd usually agree, especially as things get big.
But Kent is also pretty famous for throwing out code if things aren't shaping up. He does this in micro increments however, usually with just-written code.
I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?
Very contextual of course, but sometimes you have to explore a little bit to know the right places to make tradeoffs.
That's the main reason we have this discussion in the first place IMO. There is no one right answer to the question.
It takes many years to develop good intuition around this stuff though, so I appreciate that as a first approximation. It can get a little dogmatic amongst senior folks though.
If you are talking about refactoring or changing/replacing parts of a system - that's not the same thing. At least to me
Sometimes I just reflect on YEARS mucking with code written from someone that was just learning, and I wonder if I'm a little too in the "sunk cost investment" mindset. Hard to tell I suppose, but certainly worth thinking about.
I find it really depends on the level of nuance required of the final behavior. Maybe the test suite doesn't cover certain implicit requirements of the software, often a bug becomes a feature without anybody noticing in sufficiently old projects.
Likewise the tests might not even be structured in a way that's conducive to a rewrite, depending on their level of specificity. Maybe you only care about the final, black box behavior and individual unit tests should be thrown out so you don't need to adhere to existing function I/O requirements.
It just depends. Like you said, very contextual.
Depends how much you trust your test coverage.
Then you read his latest book "Tidy First" and it tells you when you move out multiplying width and height into an area function you have now made a beneficial design change in your system and the relationship between caller and box, a "tiny step". And suddenly all the doubts wash away.
Not sure what it is with this industry, but the writing is just useless.