Dude, you're getting old and cranky

Today I found myself opposing an initiative to have a refactoring day. I'm getting old and cranky. I really don't think I'm growing up

* When it comes to refactoring, you can't just go and change the
code without a good reason to do so. I agree that we need to address
defects from the root, but there are several problems:


Problem: Refactoring has considerable risk You may
think you're fixing bugs, but you may be creating more. Figuring out if
the time that you will spend is worth it or not is not an easy
managment decision. I have the impression that in general, no one will
just let you refactor code because the code sucks. Look at what
happened at Netscape when they decided to refactor: not only did they
open a whole new can of bugs, but they also lost the browser war.
Granted, we're not spending a year in rewriting our product from scratch, but
the point is, the code works and changing it may do more harm than
good. From the management perspective, that just makes no sense.

Problem: Refactoring drains resources from the front line
Hard fact: there are defects that make our product less-than-perfect
and they need to be fixed ASAP. Fix the defects, crank features for a
mind-boggling lightning release of OurProduct 2.1. That's what sells. A company
doesn't make a product. It makes money. We need to concentrate on good
designs, from good usability to good code. As our code base grows, it
will slowly push out legacy code. Feature by feature we target areas
that will have to get rewritten anyways, and we won't waste precious release time.

Problem: Refactoring is not the root solution
Refactoring only changes bad code that was written before. What about
bad code that will be written tomorrow? Emphasis needs to be put on
good practices and education. As we edit files, we clean them up. It's
an ongoing practice. The cleanest code is not the one that you clean up
the most, but the one that you mess up the least.

Problem: You may be refactoring the wrong thing
Relates to draining resources, but I'll compare to performance tuning.
You just don't do performance tuning wherever you think you need to do
it. It's done at the bottleneck and only when you need it. How are you going to know where your worst code is? How do you know what
refactoring effort will squash the most future defects? What will
prevent you from refactoring your now refactored code in the future
(when you decide you know better or when a new technology arises)?
Tough questions not worth the time.

* Proposed alternatives (I propose all, not some):

Alternative: Fit refactoring into your design schedule If your feature involves changing any code, make sure you take the time to change it right (not just build on top of scum).
Alternative: Educate Educate yourself on best
practices, to improve your designs and implementations: reduce defect
propensity. Educate those around you: expose more of your knowledge
through complete documentation, wiki pages, blogs. Talk to your peers,
discuss ideas like best practices. Organize training sessions. We are
in serious need of education.

Alternative: Do it on your spare time Yeah, it may
suck and I know you do have a goldfish and friends and Halo buddies to frag. It
really depends on how passionate you feel about doing things right.
Note that separating church from state is perfectly fine, the point
here is that if you want something done, just DOO EET.