KentBeck told me something ''very important'' one time.  When you are coding you should only be wearing one of four different hats.
	* Refactoring code, but only changing the interface 
	* Refactoring code, but only changing the implementation
	* Adding new functionality, but only changing the interface 
	* Adding new functionality, but only changing the implementation.
Do things a little bit at a time and limit the source of errors.  You run your unit tests before switching hats.  More often than not to add new functionality you need to do a little refactoring.  Separate the two functions don't do both at the same time, refactor then add.
----
At one point in the C3 project I had a collection of hats on my bookcase to remind me how important a habit this is to develop. --DonWells

----

We've gone Extreme, and are down to two hats now: interface or implementation. And Don is right ... it's '''very''' important.
----
Please clarify for me how you only wear two hats.  Two hats seems too few.  Are you saying that if you come to a class which requires refactoring and cleaning up for its own sake, as well as requiring new functionality, would you advocate doing both in a single step?  What we were taught is when adding new functionality, it should almost be a drop-in.  Refactoring is usually required first to make it so.  We would consider this to be two steps: refactoring and new functionality.  Would you advocate a single step?  --JeanineDeGuzman


''Not at all ... read on below ...''
----
Put me in the puzzled camp as well. Changing the Interface for refactoring vs changing the interface for new functionality seems distinct. So why drop two of the four hats? --PeteMcBreen

''We refactored the rule ... read on ...''
----
It's a two-d matrix, of course. interface / implementation vs refactor / add.

The refactor / add dimension, however, is your overall purpose. The interface / implementation dimension is the immediate purpose for your typing at the moment.

The XP rule SitOnOneCard directs that you only have one overall purpose, pins the refactor / add dimension (and also the add one thing /  add another thing).

That lets the hats refer only to your coding activity net of overall purpose.

A common strategic problem is to work on two cards at once. A common tactical problem in the heat of coding is to work on interface and implementation at once. 

Don's formulation is good advice as phrased. We now break out the two dimensions. Sort of refactored the rule.

----
I think some [/all?] of the places above where the verb "to refactor" is used, it may be an instance of an outdated term, where the later decision was to use the word "design" instead. --MikeSchwartz 

In this case refactor is correct.  That has to do with the ExtremeValues where it was decided that design was a more general term for refactor.  Refactoring is often how we do DesignInXp.  --DonWells

Ooops, yeah, See also RefactorOrDesign. --MikeSchwartz
----
Where does bug fixing fit in?  Suppose you were refactoring some code, and noticed a bug.  Do you add a test and fix it right a way, or do you postpone it until after you've finished your current refactoring?  ''Or, the third option: back out your current refactoring, then test and fix the bug.  Then, decide where to go next (this may not be the refactoring you were in the middle of!)''

----
See also RefactoringHat, RewritingHat

CategoryRefactoring