True, and hopefully nobody took my 2 examples as the only methods or suitable conditions for a rewrite. A rewrite is risk, a huge amount of risk. And often tak

True, and hopefully nobody took my 2 examples as the only methods or suitable conditions for a rewrite. A rewrite is risk, a huge amount of risk. And often taking on risk can be bad, but often taking on risk is married to the possibility of huge wins. It takes good judgment and solid development practices to take on risky projects and persevere, but it can be done, and indeed is done all the time. Going into a rewrite nonchalantly with a thousand casually made false assumptions and all the while squeezing your dev. and QA cycles between two products is a very, very common way to waste a lot of effort and seriously hurt your company, especially in the market. So be aware of what you're taking on when you take on a rewrite. As a general rule if your team/company is capable of taking on and succeeding at tasks that others typically struggle at then that can be a key competitive advantage.