A pithy way to phrase the above might be:

If you understand what it does, and you know it works, then you don't need to rewrite it!

You need to document it so you don't have to bang your head against the wall next time you look at it. In my experience, the only time you need to go through rewriting code is if the offending code needs to be extended or fixed and that is made difficult or impossible by the sheer ugliness of it.

This I guess is a corrolary to if it ain't broke then don't fix it. That law is *especially* true in software, particularly in high reliability production environments (which is all I've ever worked on BTW). If it *is* broke then that is quite another matter.

A few other methods I've run across:

1. Modularize. Have one bit of code that does one job and have it do it for EVERY possible consumer of that sort of task. I'd rather have a if-tree of slightly different ways to accomplish a task than have to go back and fix each one.

2. Test, test, and when you're done, test some more. Plan to spend at least twice as much time testing as you do coding. It stinks and it sucks but that's the only way to come out with good code. Use automated tests to cut the boredom.

3. Write readable code. Comment. Avoid the elegant approach in favor of the simple approach whereever performance allows. You *will* have to fix every bit of code that you write at some point. It's a certainty.