Regarding #1, this is now an often touted recommendation, even by folks like Joel Spolsky whom I greatly admire, but I'm not sure it's the right lesson. For example, I know that Google (at least in the 00s) rewrote huge, major pieces of their infrastructure multiple times and did so successfully. While I agree that broadcasting out a message of "We're going to stop the world and add no new features until we do a ground-up rewrite" is a bad idea, perhaps other lessons could be:
1. Don't write code that's such a spaghetti mess in the first place that you feel the need to throw your hands up and say "nothing can be done except a rewrite".
2. If you do need to do a major rewrite, make sure you have the ability to staff two teams - one doing the rewrite and another maintaining and adding new features to the existing product.
3. Kinda related to number one, but if you have well-organized code to begin with I find it's much easier to do a major rewrite in "sections" (though there are obviously difficulties with this approach).
1. Don't write code that's such a spaghetti mess in the first place that you feel the need to throw your hands up and say "nothing can be done except a rewrite".
2. If you do need to do a major rewrite, make sure you have the ability to staff two teams - one doing the rewrite and another maintaining and adding new features to the existing product.
3. Kinda related to number one, but if you have well-organized code to begin with I find it's much easier to do a major rewrite in "sections" (though there are obviously difficulties with this approach).