Wiki misuses (collaborative tools, part 1)
Great software development requires great tools; but tools do very little in themselves if the craftsman lacks the proper skills. In my (limited) experience, I have noticed that collaborative tools are often extremely useful (i.e. provide strong productivity boosts) while also being quite hard to master.
There are far too many collaborative tools to discuss for a single blog post; I will start with the wikis.
Why do you need a wiki?
There are many other ways to communicate and information within a development team, namely person to person talk, email conversations, source code comments, discussion boards, blogs, instant messengers, phone calls … and the list goes on. There is no magic in wikis; they won’t be a substitute for all that.
Let’s start with some wiki misuses, i.e. the kind of things that does not work very well with wikis. I am not saying that it is not possible to use a wiki in the situations listed below (it always “possible”); but I feel that those situations are simply ill-adapted to be handled by wikis.
Wiki-based documentations are poor documentations (probability = high)
A wiki is not a substitute for proper reference documentation. In this domain, two of my poorest user experience while trying to get some reference documentation were the WordPress wiki and the JotSpot wiki although I am quite a fan of those two products. What’s the problem here? Well, quite simply there is simply no reason for the consumer to contribute to the reference documentation (I say “consumer” to refer to whoever is consuming the documentation). Therefore, do not expect any interaction at that such level.
As a secondary point, it can also be argued that a reference documentation requires to be highly structured usually following closely the source code design itself); otherwise it’s just a pain to navigate through. Wikis do not encourage (nor provide any automated mechanisms) to support such structures. In this respect, one of best software documentation that I have ever encountered is the ZeroC Ice documentation (but I am moving away from the topic of this post).
Wikis aren’t that good for open diffusion (probability = high)
I know that Wikipedia is living counter-example of the title of this section. Yet, wikis are on average quite inappropriate for open diffusion. When I say open, I mean referring to a wiki that is not restricted to the development team.
A primary issue with wiki is that they aren’t that much appealing in terms of layout and navigation. Yes, it is possible to customize the appearance and the navigation system of a wiki, but by doing so, you’re going back to regular website development. The Math.Net open-source project is quite illustrative in this matter. Have a look at the Math.Net project page vs. the Math.Net wiki. Which one of those two pages looks better in your opinion? OK, I know you’re not going to look at those pages, so just trust me.
A second issue with wiki is that the information is usually rougher and less structured compared to classic “static” page. This point is not an issue in itself, enabling some kind of fuzzy teamwork is actually one of the main benefits of the wiki. Yet your wiki is likely to act as information pollution for the occasional visitor.
The last issue with open wikis is that they are putting boldness requirements quite high. Indeed, a main challenge with wikis is to get people involved. This point is true for almost every collaborative tool. Self-confidence is one of the strongest hindering factors when it comes to wiki writing. By opening your wiki, you are putting quite a lot of pressure on your potential contributors compared to the internal wiki situation.
More on Good wiki management soon, stay tuned…
Reader Comments (2)
[…] I have been writing about wiki misuses in the past. One of my recommendation of at the time was do not use wikis for public diffusion. I still believe that this recommendation is a good one (even highly popular forums have hard time to get anybody contributing to a wiki). In fact, even if Lokad.com is now hosted in a wiki instance, the accesses have been restricted to the Lokad team. Thus, we are using Screwturn as a CMS and not as a wiki. […]
June 16, 2007 | Joannes Vermorel’s blog
I completely agree. I set up a wiki initially for collaboration that is closed to a small group and out of that only one person sees the potential for strengthening our knowledge base and regularly contributes. I personally believe the concern with it is people do not want to give up their information unless their is some type of gain to be had from it. I have contributed to Wikipedia in the past but ultimately it was promote my own site. Selfish? I suppose but unless you provide some incentive for collaboration you will most likely only get abused by scammers and spammers.
January 21, 2010 | Fletcher