RefactorAsYouGo because BigRefactoringsAreHard

Make small changes, make them often, test them often.

	Deal with the difficult while it is yet easy;
	Deal with the great while it is yet small;

	The difficult develops naturally from the easy,
	And the great from the small;
	So the enlightened, by dealing with the small,
	Achieve the great.

----
I believe this becomes more difficult with WikiRefactoring as opposed to CodeRefactoring because there is even more emotional attachment to written words in conversation as there is to written code. --JasonYip

Refactoring for code works because it is supported by other XP practices, namely: testing, group ownership, and pair programming.  Which of those practices do we have here?

''Q: How can you test Wiki content?  I think the only thing we have is group ownership which suggests that even if we don't want to be UsingSignatures, we at least can't be too attached to what we write.''

A: http://usemod.com/cgi-bin/mb.pl?PeerReview

''In traditional PeerReview, the original author still maintains ownership.  I don't think that is nor should be the case here.  CollectiveOwnership still seems to be the only "quality control" practice that Wiki has.''

PeerReview simply means that your peers will review your actions. IntellectualProperty laws are not important. Consider a source control system in a CollectiveOwnership lab. It is necessary to frequently browse changes of your co-workers (your peers) to catch mistakes. It is in this sense that I mean PeerReview. Call it the "thousand eyeball" system if you want. -- SunirShah

----
See also RefactorMercilessly, ConstantRefactoringIsaGoodThing