"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." - Ward Cunningham
It was met with some controversy. A friend of mine responded with:
"In my experience rewrites almost never happen, and are often constrained by architecture decisions when they do. So I try to do it right the first time."
I had to jump on it... Here's my reply:
"I agree that it's hard to incorporate them if the company culture opposes it. Everyone should strives to do it right the first time but with iteration comes new information. That information can, and most likely will, lead to a better product. Typically, the reason rewrites don't happen is that they're not supported by institution/stakeholders for fear of wasted time. What they fail to see in not supporting refactoring is actually inevitably wasted by trudging on. In my opinion, that's where the problem lies. If refactoring is built into the development cycle, then it will happen. I'm not a fan of rework for the sake of rework but I do think that it's worth reinvesting in code when it's going to be augmented often.
If you're 100% happy with the work that you've done after it's been committed then, by all means, move on. However, when you know that it can be done better based on any new information accumulated through user tests, general experience, or a peer review, why not fix it then rather than allowing bulk or unwieldy code to accumulate?"