I love learning how to write better software. That was the attraction for me to the Software Craftsmanship movement. Here is a group of folks that are concerned about developing software in a way that is extensible, testable, and maintainable. I have learned so much about techniques like SOLID, different pair-programming strategies, TDD, DRY, and the list goes on and on and on.
But let’s not lose sight of our jobs here. We are paid to develop features that our customers need. Our customers are not going to care how the software is crafted under the covers, unless it gets in the way of us being able to add new features, extend existing ones, or provide a reliable platform.
We have an awesome team room where I am working, with all kinds of information radiators that help us do our jobs and communicate to our customers how we are doing. We keep our retrospective goals on 3×5 cards in a visible place so they stay fresh in our minds. Lately, as a result of some pain we felt adding new features, we have been pushing hard to refactor code that gets in our way or makes it difficult to extend the software.
Here are what two of the cards remind us about our refactoring practices:
Refactor all the time as you go.
This encourages us to keep the code clean while we are developing in, remembering the “refactor” in the “red-green-refactor” loop and avoiding the “red-green-red-green-red-green-refactor-refactor-refactor-refactor-refactor-refactor” anti-practice.
If any code is slowing you down, change it (in small slices)
This drives us to fix code that is making it difficult to maintain or extend the code.
There is no card though that says “If you see something you don’t like, change it”, and I think this is where you can get in trouble with the notion of “merciless refactoring“.
We’ve all written code we don’t like or would write differently knowing what we know now as opposed to last year, last month, or even last week. But that is not carte blanche to re-write something just because it comes into our eye-line. If it gets in our way, that’s a different story, but we need to keep our eyes on the prize and that prize is the new feature that we promised our customer at the end of the iteration.
Anyway, that’s my two cents. This soap-box I am standing on is starting to creak, so I better get down now. Please feel free to share your thoughts or observations.
P.S. In thinking about this I saw some good posts on the subject that you may find interesting:
Old Dog, New Tricks 
I agree. Re-reading the XP snippet in one of your linked posts made me think about how doing the simplest thing possible relies on an ability to change the code easily later. If we find ourselves wanting to spend an inordinate amount of time cleaning up code, perhaps we’ve left it in a state that isn’t consistent with doing the simplest thing. Maybe the guideline should be, “don’t leave a mess.” In fact, you’ve inspired a post of my own: http://ostewart.github.com/2012/07/20/when-to-refactor.html
Well put Michael. It’s all too easy to gloss over that refactor step; though I usually think of that in the context of the code that was just written. Refactoring code that slows you down (either because it wasn’t clean to begin with or because other external factors have changed) can be a tough judgement call. You’re advice to ‘keep your eye on the prize’ is the best way to make that call.