Do Wikis work for product definition/development?

I'm an engineer and an engineering manager. I recently set up a Wiki at work for design and product specifications. I like the Wiki due to several features:

• RSS feeds
• Email change notifications
• Easy to edit small documents (if you're willing to hold your nose)
• Versioning

I'm peeved by those who continue to use Microsoft Office documents instead of the Wiki. I believe almost every type of document should be in a common Wiki. But there are reasons for Wiki resistance beyond ignorance.

• Editing Wiki pages is cumbersome, especially for large documents and when you need to draw pictures or describe a complex topic
• You can't send a Wiki over email. You can't send URLs to private Wikis.
• You can't work on a Wiki while you're disconnected from the network
• Printing a multi-page Wiki topic is an exercise in frustration

MindJet's MindManager is a tool for decomposing complex subjects into sub-subjects. This tool extends beyond the typical "outliner." I often feel that I have an important thought, but it isn't ready yet to be written down formally, Wiki or otherwise. Blog entries are useful for these types of thoughts. The danger, though, is that the time won't be taken to transfer these thoughts into something more formal. The attraction of a wiki page is that multiple minds can collaborate on a single topic. Blog entries can only be commented upon and not modified directly.

Large Wiki pages are difficult to edit due to the lack of a wysiwyg editor. Creating a bunch of Wiki pages is cumbersome and it's a lot easier to create a gigantic Wiki page. Unfortunately, gigantic pages become difficult to edit and read. Also, wikis only link at the page name level and not a particular section within a page. So wikis encourage authors to keep pages focused on a very narrow subject. This is in wide contrast to, say, Word documents which are really geared towards monolithic documentation.

I have been experimenting with structures which allows you create a "book" consisting of multiple Wiki pages. I don't necessarily think this is better than, say, a powerpoint document. Powerpoint is a lot easier to read and navigate. Structures organize related pages but they don't solve all the problems associated with Wikis. The common namespace of a Wiki is a strength and a weakness. The lack of the ability to divide the namespace results in a sea of documents that can be easily lost.

As time passes, products evolve. Version 2 replaces version 1. It may be desirable to preserve the documentation for version 1 rather than replace it with version 2 contents. Therefore it seems that the best course of action is to dedicate one wiki "namespace" to each product version. A "global" wiki namespace is for concepts that are time invariant. For example, definitions of common terms.

Wikis must be topic-centric. Attempting to use one Wiki namespace for a broad range of topics results in a disaster. The need to break up Wikis into namespaces seems inevitable.

The tikiwiki.org wiki is somewhat organized by naming conventions. E.g., *Dev is a page that describes the development of a particular feature. It is therefore possible to guess Wiki page names based on feature names (at least in this case). The ability to locate page names is a pain point for Wikis.

The failure to plan for Wiki growth up front usually leads to "heat death" of the Wiki. Even doc.tw.o's wiki is separate from tw.o's wiki. It's a shame that it wasn't possible to put the Tiki Wiki docs and discussion on the same TW site.

In the early days of a project, at least, it seems that some combination of Powerpoint, blogs, and Wiki is best. Microsoft's Team Share (or whatever) seems like the best commercial solution out there. Every marketing wonk I know writes Office documents and it's nearly impossible to make them change their habits. Pretty soon you get tired of beating your head against the wall. At least you can paste Office documents into Wiki pages, as long as they don't exceed PHP.ini's upload, processing time, and memory settings and MySQL's packet size setting, which is another pain point.

See the "namespace" section in WikiDev for further discussion about Wiki namespaces.