Only Wear One Of Four Hats

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!)