If you have a poorly factored program that does what the customer wants and has no serious bugs, for the love of Mike leave it alone! When you need to fix a bug or add a feature, you RefactorMercilessly the code that you encounter in your efforts. Thus, RefactorMercilessly can live in harmony with IfItIsWorkingDontChange. -- rR

-------------

I suppose if you want to eat big-time long-term maintenance costs. I think offshore outsourcing will actually decrease the quality of code because it is cheaper to throw bodies at the problem. So what if you have to make the same change in 30 different places, you have 30 people earning $1.50 an hour.
 
----
That's valid if you can assume that no serious bugs or enhancement requests will ever arise. In the real world, refactoring is almost always worthwhile to improve future maintenance.

'''But''' why guess at what might need future maintenance when you've got code that needs maintenance now?  YouArentGonnaNeedIt.  Refactor the parts that have outstanding bug fixes or feature requests pending, so that you can easily fix the bugs or add the features.  Only if you have absolutely ''nothing'' to do would it be worthwhile to fix what's working, and then only if you've got UnitTest''''''s to keep it working.

----
The relativist says: "Working code trumps everything except code that works better."

The Orwellian says: "All working code is equal, but WellFactoredCode is more equal."