Here's an analogy that illustrates the difference between refactoring and rewriting.
Imagine that you're a young boy, sitting in your room, playing with a Rubik's cube. It's all jumbled up, and you want to solve it before dinner. Your mom is going to call you to dinner in fifteen minutes.
Okay, the analogy here is that the boy is the programming team, the Rubik's cube is the application, and dinnertime is the ship date. The cube is jumbled up, but it's still in one piece: the application works, but it doesn't have everything neatly lined up.
So you want to solve the Rubik's cube. What do you do?
Well, when I was kid, I took a screwdriver to it. I levered out each of the little squares - sproing! - and then fit them all back together in the correct order. The problem was that sometimes the pieces went flying across the room. Sometimes I couldn't find them all before dinnertime, and my cube ended up with pieces missing.
I had a friend who was a little more determined. You might even say plodding. He would turn the Rubik's cube back and forth, back and forth. He would think a lot before making each turn, so he wasn't usually done before dinner either. But every turn he made got the cube a little bit closer to being solved. When he got called to dinner, the cube wasn't always done, but it was always in one piece, and it was always better off than when he started.
Rewriting software is like taking apart a Rubik's cube. It's tempting and easy, but you run the risk of losing a piece. Refactoring is like solving the cube. It's kind of boring, and it requires you to think a lot, but turn by turn, the application gets better. You never lose a piece.
Some people are whizzes with a Rubik's cube. They can solve it faster than I can take it apart and put it back together again, and they never lose a piece. If we practice refactoring a lot, we'll be able to do the same thing.
By the way... don't refactor only before dinner. Do it constantly. It's called continuous design, and believe me, it's better.