Consider that each page in Wiki is just like a ''class'' in an object-oriented language like Smalltalk or Java or C++. In fact, it's very close to being isomorphic.

Consider good class design:

	* Good classes have MeaningfulName''''''s
	* Good classes have well-defined, well-delimited roles
	* Good classes have well-defined, well-delimited responsibilities
	* Good classes are related to other classes in the system (collaborators)

Consider good page design:

	* Good pages have MeaningfulName''''''s
	* Good pages have a well-defined, well-delimited focus/topic
	* Good pages/topics have facets that need discussing
	* Good pages have links to and are linked to by other pages

Now, many operations are ''preserved under isomorphism'' such as RefactorMercilessly. In fact, you can apply RefactoringPatterns to Wiki pages. Consider RefactorByExtractingToPage as a transformation of ExtractClass.

RavioliWiki is an isomorphism of RavioliCode. Too many purposeless, unfocused pages with no real purpose in the system and a very low fan-in and fan-out rate. 

See also AvoidClutterLinks.

----

So, now that Wiki has tens of thousands of pages, how many people would say it isn't RavioliWiki? Just look at how many pages have "see alsos" to pages with the exact same topic, but with another name. -- SunirShah

----

I think that RavioliPages are great. It gives people a place to scrape irrelevant stuff into. If the pages aren't interesting they'll scroll off of RecentChanges soon enough and if they are, they'll have a place of their own where they can grow. In the meantime it's easier to keep the original page short and to the point because people will be a lot more comfortable moving stuff than they will be deleting it (although there is a place for that too). -- PhilGoodwin

Being short and focused is great, but you quickly build duplications as points are repeated over and over, page after page. It is already far outside the ability of a HumbleRefactorer, apparently, to link seamlessly with RefactoringWikiPages which would have served better than the newer RefactorFasterDeleteMore. 

You know, if you ExtractClass ''this'' frequently and ''this'' mindlessly, your code will become insane. And I thought ''I'' was bad with a median class length of 200 lines (between .h and .cpp files) and five methods. Of course, I take great steps to ensure there are no redundant classes when I'm done. ''nudge, nudge, wink, wink, say no more.'' 

''I am not convinced the analogy RavioliCode / RavioliWiki works too well. Wiki now has > 7500 pages, and I don't think it would feel significantly more (or less) overwhelming if it had twice (or half) as many. 7500 classes... that would be a different story. --FalkBruegmann''

I agree with Phil and Falk that the analogy here is really faulty. EwDijkstra complained that programming ''language'' was the wrong term, because they just ain't like human languages. I wouldn't go all the way with him on related issues but I think this is a very relevant point here.

I believe that one of the reasons that we have SoManyMoreWritersThanRefactorers is that some of the original material on refactoring turned out to be unrealistic about how difficult it is to refactor Wiki really well, especially with the current level of new visitors and changes.  We need more realistic guidelines. I put up RefactorFasterDeleteMore to make a small contribution to developing consensus on that more realistic picture. I'm also very grateful now for WikiRefactoringStories.  

In Smalltalk I believe in short methods and, to a lesser extext, in short classes. On Wiki I would like much less text within (possibly) more pages.  I believe that, as a general rule, short pages with the right links are more readable than longer ones. Our aim is to ImproveSignalAndReadability.

--RichardDrake

''The dichotomy between natural languages and formal languages is only in their levels of adaptability and systematic constraints. However, the information capability is ''almost'' equivalent between the two (but not.. see GoedelsIncompletenessTheorem). I think it's one of the great failures in the pedagogy of computer science that students aren't subjected to a year's worth of InformationTheory. The page::object analogy is still sound because they both are information containers with names, roles, foci and responsibilities organized in a similar graph. Hence, they are still analogous, approaching isomorphic.''

Without wishing to cast aspersions on anyone else's isomorphisms, I believe that we need to consider some other points if we are wondering why Wiki as a whole isn't as well factored as, say, the famous Smalltalk/Gemstone code at Chrysler. We could look at the following set of pages 

	* [] RavioliWiki (or NotUnderstandingClassPageIsomorphismWiki)
	* [] LargeProgrammingTeamWiki
	* [99] DistributedProgrammingTeamWiki
	* [] LackOfTuringCompletenessOfTheImplementationLanguageWiki
	* [] LackOfPlanningGameWiki
	* [] LackOfUserStoriesWiki
	* [5] LackOfUsersWhoArentProgrammersWiki 
	* [] LackOfClearCutCoachWiki
	* [5] LackOfUnitTestsWiki
	* [] please add

Anyone want to vote on which has been the most significant? --RichardDrake

----

Umm... could it be that coding is about producing a program that has to run, has to be focused on meeting set requirements with a maximum of clarity and minimum of duplication and unnecessary effort, while Wiki is a mirror reflecting the
opinions and thoughts of a wide community of different people?

I don't want to live in someone else's poem. -- JamesNoble

----
See also ProgrammingIsLife, QualityWithoutaName
----
CategoryWiki CategoryWikiMaintenance