A reference to "What Would Jesus Do", although comparisons between KentTheBeck and Jesus are not what I'm thinking. Kent may think what he wishes in this regard.
Not a fan page, and Kent probably should be writing here!
Anyway, these are thoughts of what has helped me in my software engineering work which I've gleaned from his SmalltalkBestPracticePatterns book, ExtremeProgramming, and his keynote address at the Smalltalk Solutions conference in NYC in 1999 (which lead me to his book and XP), e.g.
Refactor doesn't mean "don't write a line of code twice", it means, "eliminate duplicate code". If you literally wanted to keep from writing a line of code twice, it would mean that every time you wanted to write a line of code, you would have to search the entire system and look for a line of code like the one you wanted. When you are writing code, you should spend at least a few seconds thinking about whether there is something you can reuse, but your main focus is on getting your test cases working. Once you have them working, then you refactor. So, refactoring is about ELIMINATING duplication, not making sure it never appears. Refactoring is more than just eliminating duplication, since it is also about picking good names and simplifying interfaces, but it is a major part of refactoring.
-- RalphJohnson
Well said, sir. What you've described is more in line with what I do: write, test, *pause*, ponder, refactor. Refactoring usually comes to mind after I've looked at the code a while, and it tells me, "Say, Doug, this is the fourth time you've written this sequence. Howsabout refactoring?" So, I've changed the bullet item above. See DoTheSimplestThingThatCouldPossiblyWork for some discussion on the RefactorMercilessly tradeoffs. ThreeStrikesAndYouRefactor