I always enjoy reading or listening to Martin Fowler. The following comes from his book, Refactoring.
_________________

The word Refactoring has two definitions depending on context. The first definition is the noun form.
Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheapter to modify without changing its observable behavior.

The other usage of refactoring is the verb form.
Refactor (verb): To restructure software by applying a series of refactoring without changing its observable behavior.

So, you might spend a few hours refactoring, during which you might apply a couple of dozen individual refactorings.
…
Since I’ve been using refactoring, I’ve noticed that I clean code far more effectively that I did before. This is because I know which refactorings to use, I knnow how to use them in a manner that minimizes bugs, and I test at every possible opportunity.

The purpose of refactoring is to make the software easier to understand and modify. The second thing is that refactoring does not change the observable behavior of the software.

The Two Hats
This second point leads to Kent Beck’s metaphor of two hats. When you use refactoring to develop software, you divide your time between two distinct activities: adding function and refactoring. When you add function, you shouldn’t be changing existing code; you are just adding new capabilities. When you refactor, you make a point of not adding function; you only restructure the code. You don’t add any tests (unless you find a case you missed earlier).

As you develop software, you will probably find software swapping hats frequently.

Why Should You Refactor ?
Refactoring is no “silver bullet”. Yet it is a valuable too, a pair of silver pliers that helps you keep a good grip on your code.

Refactoring Improves the Design of Software
Without refactoring, the design of the program will decay. As people change code-changes to realize short-term goals of changes made without a full comprehension of the design of the code-the code loses its structure. It becomes harder to see the design by reading the code. … Loss of the structure of code has a cumulative effect. The harder it is to see the design of the code, the harder it is to preserver it, and more rapidly it decays. Regular refactorings helps code retain its shape.

Poorly designed code usually takes more code to do the same things, often because the code quite literally does the same things in several places. This an important aspect of improving design is to eliminate duplicate code.

Refactoring Makes Software Easier to Understand
Someone will try to read your code in a few months’ time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important. Who cares if the computer takes a few more cycles to compile something? It does matter if it takes a programmer a week to make a change that would have taken only an hour if she had understood your code.

Refactoring Helps You Find Bugs
Help in understanding the code also helps me spot bugs. If I refactor code, I work deeply on understanding what the code does, and I put that new understanding right back in the code. It reminds me of statement Kent Beck often makes about himself, “Im not a great programmer; Im just a good programmer with great habits.” Refactoring helps me be much more effective at writing robust code.

Refactoring Helps You Program Faster
In the end, all the earlier points come down to this: Refactoring helps you develop code more quickly.
This sounds counterintuitive.
I strongly believe that a good design is essential for rapid software development. Without a good design, you can progress quickly for a while, but soon the poor design starts to slow you down. You spend time finding and fixing bugs instead of adding new function.