Jim's been drinking the unit testing kool-aid. Awesome. I have a little more for him. :)

Seriously though, strictly speaking you shouldn't refactor just because the code *looks* icky. Here's the thing about unit tests: they can be just as buggy as the code they are testing. They can do a good job of pointing out regressions, but they will probably not get them all. It depends on the quality of the tests, which is hard to determine. (You're not going to test the tests, are you?)

In fact some teams, for the sake of agility and speed, only code unit tests for common or complicated situations/breakages and do not attempt to cover all possible regressions. If you have really great programmers, your team can get away with shortcuts like this.

You can easily refactor an "ugly" piece of working code into a beautiful piece of buggy code and be none the wiser. Even WORSE, is thinking that because you have unit tests you have NO BUGS in your newly refactored code. Ack! Unit testing should give you more confidence while you refactor but not that much confidence. :)

This is why extreme programming promotes refactoring only at the last possible moment. If you have a bunch of ugly but WORKING code, leave it until you absolutely need to refactor it to add a new feature or to make the code simpler to solve another bug. Then you won't risk adding bugs just making your code beautiful or fit some established pattern.

As a related aside, XP also promotes refactoring early in an iteration rather than later. This is why in XP you implement the "riskiest" bugs first, where part of the risk measurement is how much of my application's code will I have to refactor to add this feature?

The reason you don't want to refactor established code: this ugly working code has stood the test of time. It's been beaten down by your users, it's been tested to hell in the UI by manual testers and QA people determined to break it. A lot of work has gone into stabilizing that mess of code you hate.

As much as it might pain you to admit, if you refactor it you'll throw away all of the manual testing effort you put into it except the unit tests. The unit tests, as I said earlier, can be buggy and aren't nearly as comprehensive as dozens/hundreds/thousands of real man hours bashing against the application.

Developers especially have to resist the temptation to refactor code to "beautify" it at the end of an iteration or development cycle. They'll really be tempted to, but swat their hands. Playing with the code can just introduce new defects.

Bottom line: code entropy is your enemy and you should only refactor when absolutely necessary. The more code you can keep still and not stir up, the bettter. Don't let this scare you off from adding new features and refactoring, just keep in mind how much entropy you are introducing into your project.

Before you refactor, take a minute to think about how much testing effort it will take to get to the same quality level you're at right now despite your messy code. Is the refactor worth it?