Does your team use a Wiki?

We've been using an internal wiki for about a year now for all sorts of collaboration with great success. I bet many teams could benefit from a wiki, but either haven't ever heard of them, or think they are hard to set up. I thought I'd write a post on this to encourage you to give it a try.

We've tried an internal blog, a FrontPage maintained web-site, e-mail, Sharepoint etc... and all have their strengths, but the wiki remains my favorite way to quickly share many types of information among the team because it's virtually frictionless for both the contributors and the readers. And as we all know, for us lazy developers it's all about removing the friction.

A wiki is a web site that can be quickly edited with nothing but a browser. Wiki's work well for frequently changing information because it is so quick and easy to make edits. (It's like notepad for the web). Contributors are much more likely to keep the content fresh than in any other web-publishing scheme I've used. There are many implementations of wikis out there, but the one I have experience with is the open source FlexWiki (http://www.flexwiki.com) which is a fine piece of software. It is easy to install and be up and running in minutes.

It takes seconds to make an update to a Wiki page (at least in FlexWiki). Double click the web page you are viewing, type in your change, and click save. Most other publishing schemes introduce significantly more "friction" both for contributers to publish their information and for consumers to find and read it. This leads me to an obvious observation:

The greater the friction in a process, the greater the chance it will not be used.

The additional friction contributes to a stale data problem. The contributor may have some information to release, but because publishing the information is non-trivial, they say to themselves...I'll do it later. Then the information becomes stale, and end-users who need the information stop consulting the source because it's not accurate.

Some examples where I've found wiki's work well:

  • One group that is producing a web application uses it to keep track of what build is in each environment, and the wiki page has links that take you directly to the app. This information changes often, and the wiki has become the definitive place for everyone in the department to go. (I've seen some people set this wiki page as their start page).
  • It works well for installation instructions, checklists and how-to's
  • It works well for status reports
  • It works well at a project's startup phase where team members are collaborating on strategy and research
  • It works well for all kinds of documentation

It isn't ideal for discussions because there isn't a built in concept of "thread", it's just free-form text. You can get it to work if you have an agreed-upon convention of attributing your posts with your name and date or something like that.

In FlexWiki you can subscribe to e-mail change notification newsletters and RSS feeds so you get notified when a wiki has been changed which is very nice. Additionally FlexWiki has an extensibility API so you can plug in dynamically generated sections. For example a download portal where a plug-in renders a table with download links to all of the available versions based on the contents of some directory.

So maybe give it a try sometime.

3 Comments

  • More like FlexBuggy! They keep adding features but keep letting bugs stagnate.

  • We haven't had _any_ problems at all with FlexWiki, but we must not be pushing it as hard as seapirate is.

  • Wikis are great, I've been using them for years, for many purposes! My current employer uses MediaWiki, which I would recommend if you're on a linux/php platform.



    The only problem is that using a wiki is somewhat of a paradigm shift. Some people will just never get used to the idea of an editable web site. Too bad, because it's the greatest collaboration tool ever!

Comments have been disabled for this content.