I keep hearing this nonsense over and over. I've led two full and very successful software 50-100K LOC rewrites, both with the team and stakeholders who had a lot of experience in the problem space. We replaced unmaintainable systems by a much fresher, MUCH faster codebase. They used largely boring and reliable technology. Rewriting 1%, 10% or even 50% would make no sense and essentially get us little or nothing.
Yes, you need to know what you're doing if you plan to rewrite anything, and make sure that the people who know the little legacy details of your system are around, but it's absolutely the right thing to do in many situations.
The thing is, there are a lot of small systems maintained by a lot of small teams. Unfortunately, when Joel wrote
“They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.”
some people took the “any software company” to heart and now apply the same principle even in those smaller contexts when sometimes the code really is that bad and rewriting the whole thing really is by far the best plan. I’ve seen very senior people citing the Netscape case study to support a no-rewrite position while discussing a 10kLOC system that could be rewritten from scratch in a couple of weeks by a single developer.
Yes, you need to know what you're doing if you plan to rewrite anything, and make sure that the people who know the little legacy details of your system are around, but it's absolutely the right thing to do in many situations.