In part 5 of The Big Swinging Developer Test (a parallel to The Joel Test: 12 Steps to Better Code) we get into refactoring.

The Joel Test:
5. Do you fix bugs before writing new code?

The Big Swinging Developer Test:
5. Given a piece of ugly code do you refactor it before adding new functionality?

This is the first time that the 2 tests seem to be talking about different things since refactoring is not the same as bug fixing.  The key here is that it isn’t a question of technique, it’s one of discipline and motivation.  A lot of organizations are feature oriented.  They feel judged based on the quantity of functionality delivered and will try to maximize quantity at the expense of quality.  I’m pretty sure that this question made the Joel Test because it tells you a lot about the medium-to-long term outlook for working in such an environment.  Imagine being given no time for defect fixing post-release.  Or worse, being told that you get no time because, "You should have done it right the first time."  Oy!

The Big Swinging Developer question tells you a lot about the medium-to-long term state of your code.  Let’s take the typical example: You’ve inherited a bunch of code that was written by several people.  You can see places where something started to rot and then was made worse by each subsequent developer.  Nested "if" statements get deeper.  "Switch" statements get more and more cases.  Methods grow to screen, after screen, after screen of spaghetti.  You get the idea.  After being given this mess and told to add functionality to it, do you create another layer of mess or do you take the opportunity to put a stake down as the the beginning of things getting better?

As you might imagine, the decision gets easier as your refactoring skills improve.  If you’re already comfortable with unit testing, cyclomatic complexity, and have read Martin Fowler’s excellent book on the subject then you’re more likely to jump right in.  If you’re a bit squeamish, however, then that’s a pretty good indication that this is an area to build up your skills.  Fortunately, this is pretty easy and the practice work will be beneficial to you and your employer. 

Refactoring starts with writing unit tests.  Unit tests tell you that you are retaining the original functionality, which is a refactoring requirement.  You can always add/subtract/edit functionality after refactoring, but you can either be refactoring or changing functionality – never both at the same time.  Once you have a suite of effective unit tests (which is an immediate benefit to your employer) you can start cleaning and simplifying the code.  The links above will lead you to some excellent sources for information and techniques on how to do this.  Change the code, run the tests, repeat until satisfied.  After only a little experience with refactoring you’ll be much more likely to leave any code you touch in better shape than when you inherited it and making things better is what being a Big Swinging Developer is all about.