IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerworks > My developerWorks >  Dashboard > Bobby Woolf: WebSphere SOA and J2EE in Practice > ... > Miscellaneous Non-Technical > Why Wikis are Valuable
developerWorks
Log In   View a printable version of the current page.
Overview Connect Spaces Forums Wikis
Why Wikis are Valuable
Added by bwoolf, last edited by bwoolf on Nov 29, 2006  (view change)
Labels: 
(None)

Why Wikis are Valuable


What's so great about wikis anyway?

A wiki is a set of Web pages that any reader can edit and update. It is a great way for a community to document their group knowledge about the topic(s) they're interested in. Members add content to capture bits of their knowledge on an as-needed basis; other members read this to learn the knowledge, and are able to add their own knowledge by adding content to the pages. The members can and should refactor the pages to encapsulate the knowledge into individual, reusable subjects, and should link to those pages whenever those subjects are mentioned to reuse the knowledge.

By default, anyone can read and edit a wiki, but some wikis limit this. Some wikis control who can read them, such as hosting a wiki on an organization's internal server that is not accessible from the Internet, or requiring registered users to log in to read the wiki. Wikis can also control who can edit them, so some users may be able to view a page but not edit it. Still, for those with permission to view and edit pages, the idea still holds that a reader can change a page when he wants to.

When a project uses a wiki to communicate, it documents its work as it goes along. This is great when someone asks, "Why did we decided to do X this way?"; go check the wiki. When a team member forgets or ignores a decision, remind them by telling them to go read that decision page again. When a new member joins the team, they should be able to come up to speed on the group knowledge by browsing the wiki.

Wiki Examples

Two of the best known wikis are Ward's original WikiWikiWeb and Wikipedia. They're both public in that any WWW user can read and change them. Some wikis are private, controlling who can read or edit them, either by hosting them on an intranet and/or by requiring a login. There are public Wiki farms you can use to start and host a new wiki.

My wiki is actually a somewhat limited example of a wiki, because only I can edit it (but any WWW user can read it). So mine represents a community of one, me. Why? Because it's an extension of my blog; see Wiki vs. Blog.

How Wikis Work

When a project uses a wiki to document what they're doing, that's a Content Creation Wiki. The natue of wikis is that they're never finished, and parts are usually incomplete; that's the nature of evolving understanding, documentation of that understanding, and consensus building. The wiki content generation process is non-linear; get used to it. You'll see a lot of that in my wiki, as I strive to document what I know that I think will be helpful to readers; a lot of stuff is incomplete, but hopefully better than nothing.

When people first start learning how to use a wiki, they tend to focus on content creation. There's also hopefully content consumption, since the wiki isn't supposed to be a write-only medium. Another important (and often unappreciated) role is the wiki gnome, whose efforts keep the existing content organized: edit existing content, refactor onto appropriate pages, add links, consolidate ramblings into quick explanations of consensus, update external links, etc.

Wiki Effort


How much time does a wiki take to build and maintain?

This is a bit like asking, "How much time should an employee spend reading and writing e-mail?" As much as is needed to help them do their job. Not so little that they're out of the loop, but not so much that they're overwhelmed.

Developing a wiki takes as much time and effort as you want, and as much as you need to do the job decently. Like any documentation effort, too little doesn't communicate the knowledge needed; there's also a point of diminishing returns, where more effort outweighs the additional knowledge created.

A wiki is a quality effort; you can neglect it when times are tight, but then quality suffers. For a team to have a good wiki, the team members who work on it need to receive reward and recognition, or else they'll quit doing it. Part of this is giving them the time they need to contribute to, maintain, and consume from the wiki. This should be part of their job duties, like writing and testing code. If the team treats the wiki as unimportant, and treats the work team members do on the wiki as unimportant, then the wiki will indeed become unimportant.


 
    About IBM Privacy Contact