Kismet...I think Jeff was expressing much the same sentiment in his last Coding Horror piece: http://www.codinghorror.com/blog/archives/001160.html

Yes. But this one is expressed more clearly, more directly, and without the sensational headline hyperbole.

Does no one write code in their head before putting it in the editor?

I think people used to do that in the days of punched cards.

More seriously, I have been known to spend weeks thinking about the code I'm about to write, but I only really think about the general form and structure of the code. I don't really get too into issues of the precise syntax until I start actually "putting it into the editor".

Nail.head(hammer)

This has been the most effective approach for me as well, and likewise, I didn't really discover it until I started working in Ruby, and interestingly enough, now that I'm a lot more willing to hack a solution together and refactor the hell out of it, my C programming has gotten a lot better as well.

Even though I still have to force myself into this behavior most of the time, the productivity benefits are pretty unquestionable.

The danger is that you have to discipline yourself to refactor -- you can't just stay in hack mode or it's Big Ball of Mud time. Hack-and-refactor is a straight and narrow path. It's hard for analytical modelers like me to commit to the hacking part; it's hard for go-with-the-flow cowboys to commit to the refactoring part.

Actually, my problem is disciplining myself to hold off on refactoring. But I understand what you mean -- there are far too many people who aren't interested in going back over stuff they've already written.

The "ship it" rubric very often trumps the refactor debate; coders and managers tend to see the refractoring entirely differently.

What James is referring to is not necessarily stripping out big pieces of code when they've been working in production for a while. Rather the point is that in a given coding sprint, he gets the first thing that works going, then starts from there and rewrites them better if need be. So it's just an approach to developing a given method or class rather than refactoring for the heck of it.

I know what he's referring to.

You're a coder. I'm a coder. James is certainly a coder's coder. But stop thinking like a coder for just a moment, though.

Having (functional) product out the door (faster) beats having (better) code in the market (later). Every time.

Do I defend this? Yes and no.

Have I experienced this? Yes.

Wearing my manager hat, the product ships. Code refactoring is extremely difficult to justify.

Wearing my coder hat, I refactor and re-comment and rework and update the test cases while I still remember what I was doing with the particular routines. Then I move on.

This is the age-old conflict between better and faster; elegance and schedule. It's why managers and coders are so often in conflict, too.

True, but code is rarely ever shipped then abandoned. Refactoring is (hopefully) all about making code more manageable and as reusable as possible, not attaining some sort of aesthetic elegance.

I totally agree, and this is exactly what I do an the method/micro level. Generally I can get something working in just a few minutes but then I spend another 5-10 really polishing it up in 5+ small iterations on it (all test driven, so I know my changes still work).

Hoff's point was well above that, at the design/macro level. For that I alternate releases between adding features and house cleaning (bug fixes, refactorings, etc). With a sufficiently short iteration time, you can appease both the client/users with new features and the developers by keeping things clean and happy.