From BigRefactorings:

	 :	A refactoring is big if you have to make more than 5 minutes worth of changes before you can run the unit tests.

BigRefactoringsAreHard because:

	*the effort in making a change is proportional to the size of the change (obviously)
	*the comfort in making a change is inversely proportional to the length of time between receiving concrete feedback on whether the change has broken anything
	*BigRefactorings have similar properties to BigDesignUpFront

The solution is to RefactorAsYouGo.  Make smaller changes, make them more often, test them often.

See HillClimbingDesign
----
'''Discussion:'''

In terms of WikiRefactoring, BigRefactoringsAreHard usually because ThreadMess has been allowed to set in, making it very difficult to resolve multiple dependencies and redundant statements.

----

The solution is not necessarily to RefactorAsYouGo. That is a greedy approach and can only locally optimize. Sometimes large changes are needed to shake the system towards the global minimum complexity. However, BigRefactorings aren't necessarily hard with tests or other similar scaffolding. One strategy is to rewrite the offending code from scratch, pushed in from the tests or scaffolding. It fails on one call, implement the call. If doesn't take you where you need to go, write more tests so you force yourself to go that way. --SunirShah

Hmmm... another example... I think Sunir has a valid point but I don't want to refactor to add it to the top statement until it is discussed further... so my Spidey Sense is now tingling...  What I'd like to see is a to-do list on the side of EditPage with target refactorings...

In any case, the issue seems to be whether strategic movements can be derived from a collection of tactical movements.  I think small refactorings can still be done for a strategic goal vs just a tactical goal.  If you look at some of the refactorings in the "book", there are steps that are done solely to prepare for the next move and are not necessarily moving toward a local optimization. Perhaps that's another reason why BigRefactoringsAreHard, you have to maintain a position that is neither locally or globally optimal for a sustained period. -- JasonYip
----
A modest proposal for automated WikiRefactoring: GarbageCollectionForWiki