Comment Joel on Software explained it in 2000 (Score 4, Informative) 48
Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes.
Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
It is true today. All that complex code is money: it is functionality the user (or the marketing folks) want to sell more, to provide better service, or to differentiate. Simple code is for textbooks. Complex, crufty, miserable code reflects the complexity of a successful business or a highly-used open source project.
Why? Try explaining the rules of English spelling or grammar to someone. It requires many special cases, exceptions, and exceptions to the exceptions. Business processes are, sadly, the same way.
Should you refactor? Of course, when doing so allows faster fixing of bugs or adding new features (i.e., when it makes it easier to make the code more functionally complex.)