

Wearing Out My Delete Key - dhotson
http://jamesgolick.com/2008/8/4/wearing-out-my-delete-key

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

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

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

~~~
qwph
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".

------
donw
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.

~~~
iron_ball
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.

~~~
donw
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.

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

~~~
possiblemat
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.

~~~
Hoff
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.

~~~
jordyhoyt
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.

