The answer to a Non-Rigid-Organization

Japanese philosophy is so near to computer-science

Do you remember? Some days ago I suggested some ways to do data-entry, but I didn't explain well when a wiki is a good solution. I want to illustrate better this concept and introduce you some cases where a wiki is a comfortable solution.

Wabi-Sabi

What's Wabi-Sabi? In wikipedia we read

Wabi-sabi (侘寂?) represents a comprehensive Japanese world view or aesthetic centered on the acceptance of transience. The aesthetic is sometimes described as one of beauty that is "imperfect, impermanent and incomplete".[1] It is a concept derived from the Buddhist assertion of the Three marks of existence (三法印 sanbōin?), specifically impermanence (無常 mujō?).
Characteristics of the wabi-sabi aesthetic include asymmetry, asperity, simplicity, modesty, intimacy and the suggestion of natural processes.

Do this sounds familiar to you? Concepts like "transience", "impermanence", "incompleteness" can appear very often in a bad organized office and are programmer's hell. Let's think to write a relational database. It's well designed and has good interfaces for CRUD. Now, let's imagine our boss asks us to change the relational schema. Adding or removing a column could be not very difficult, but changing big pieces of this schema means to rewrite our application controller from 40% to 70% and write some scripts to move datas from the old schema to the new. Pretty boring and frustrating. And, more important, probably non definitive, because in a bad organized office, changes could happen very often.

Wiki is Wabi-Sabi

A wiki is "fluid". It have a very simple schema (to our eyes), mostly based on "Articles" and "Categories". It checks if a certain page exists (blue links) or not (red links); it lists all uncategorized pages; it lists all unused categories, ecc. It will also include the "Search" which shows us all pages wich contain the searched word.
I choose a wiki for a particular job: I had a web application and I have to list all entities showed to the user. I started with an excel spreadsheet, listing where the entity was located (in wich web page), if it was read or write, who can modify it and other fields. This organization changes some days ago, forcing me to change the schema. But this time I moved all data to a wiki (mediawiki), making a page (article) for every entity.
Result: it's appreciated and a change will be managed easily, 'cause there's no SQL schemas to modify, just pages.
If you're losing your life on a Access database and your boss wants every day a "small change" which makes you mad, then moving to a wiki is probably the best solution.