Skip to page content or Skip to Accesskey List.


Main Page Content

When Wikis Go Bad

Rated 4.18 (Ratings: 3)

Want more?

Picture of quiraang

Simon MacDonald

Member info

User since: 24 Oct 2008

Articles written: 1

Over the last few years the use of wikis has become really popular. For every wiki evangelist I have met, I have also come across

as many who hate wikis. I’ve used them extensively and I too have gone through

a love-hate relationship with the wiki. I’ve probably used wikis for most of

the common applications:

  • Project management
  • Documentation and knowledge bases
  • News letters
  • Community portals

Having recently done some work on the href=""> wiki, I decided to

write down some of my thoughts about why sometimes wikis are phenomenally

successful, and others just never seem to work.

Like a lot of similar issues, none of this is rocket science.

(This is not meant to be a history of the wiki; if you want to know more

about wikis go to the Wikipedia


Where can a wiki go


The answer to the above question is in lots of ways! I’ve categorised these


  • Content
  • Complexity
  • Community
  • Corporate

However, there is an inter-relationship between

these, inasmuch that a failing in one area results in failings in other areas.

Nonexistent or inappropriate content

For a wiki to be successful, like any other website, it

needs content. Not just any old content, but content appropriate to the aims of

that particular wiki. I’ve seen bare bones wikis chucked over the wall at a

group people who have been told to use it and who, unsurprisingly, have ignored

it. My approach is to spend a little time in putting some outline structure on

the initial wiki and add some sample documents so that users understand how it

should be used.

An example is a professional community portal wiki where I

was a user. The aim of the portal was as a reference site to assist with

professional and career development within this particular company’s

organisation. The idea being that it would promote a sense of community and users

would be able to look at job vacancies, find out about training courses, and ask

questions in various forums. It didn’t work. Once you got past the fancy front

page, many of the links lead to pages that were under construction,

or held out of date, and even incorrect information. Initially, there were a

few comments added to a few pages, but these rapidly became Hello, is

anybody there


Sometimes wikis are wildly successful, with lots of content,

and then suddenly the usage drops. Often the cause of this is that there is

just so much content, and so many links and pages, that the information you want

can’t be found. OK, there are search engines in the wiki, but these often aren’t

sophisticated enough to be of much use.

Now, all of the above is not unique to wikis, but just as

applicable to any website. The trouble is that people have been told that this

fantastic wiki thing will solve all their problems, and when it doesn’t

deliver, it’s that wiki that gets blamed.

Too much complexity

A wiki should be simple to use and navigate, and should grow

organically. Most of the successful wikis I have seen have used simple open

source products, with a lightweight structure put in place to organise the

information, and with lightweight moderation to manage the site.

One of the unhappiest wiki experiences I have had was when the

company I worked for bought an Enterprise Wiki product. It was a great product,

but it had an orchestra of bells and whistles that you could use to enhance

the wiki experience
. We were using it for documentation and we had a

globally dispersed team, centred on a small UK based core who would write the

bulk of the content, and the other folk around the globe could edit the pages

to add in the text for their part of the project. In theory this should have

worked well, but for the fact that the manager who ran the site was a

techy and used every possible gadget in a set of templates embedded

within other templates, that made editing anything a complete nightmare, even

for the wiki-literate. The rest of the team did not stand a chance of getting

to grips with it and as you might expect did not add content to the wiki. The

target did users did not use it either, because it was either incomplete, or out

of date. It looked pretty, though.

So the moral of this, is KISS.

Managing the wiki community

Understanding, and educating the target community for the wiki is really important.

Some basics:

  • There needs to be a sysadmin person who is wiki-literate and can act as a moderator for the wiki.
  • Is a wiki the best answer? Wikis tend to be regarded as a solution for many problems, maybe some other solution like a blog would be better.
  • Does the community see the benefit of using a wiki? Sometimes they work surprisingly well. I used one on a globally dispersed agile development activity, where time differences meant it was difficult to schedule daily review calls. The wiki was used as the core of the reporting for the agile activities. So, if the call was timed to suit the West Coast USA, people in Asia could update the wiki with progress and issues, instead hanging around for a conference call at some anti-social hour.
  • When people

    are new to wiki concepts, it takes a real mental gear change for them to understand that

    anybody can edit a page, or add a new page. It takes a while for them to understand they can make changes themselves instead of emailing the author or moderator, or leaving comments, asking them to make changes.
  • Once they are up and running they still need a wiki champion they can go to, to ask questions - usually the moderator
  • It's a popular misconception that wikis run themselves. The wiki moderator has a really important role. Looking after the user community, keeping the wiki tidy, monitoring page usage, maybe adding direct menu links to popular pages, looking out for orphan pages, and generally looking after the health of the wiki.

Corporate control

I worked for a large global company that has a massive intranet.

It had an enterprise wide product licences for Content

Management and also Document Management, all controlled centrally and there were corporate edicts that thou shalt use them - or else. Unfortunately there were huge bureacratic hoops to jump through to even start using them, and when you did they were real pigs to use.

Suddenly wikis started popping up all over the intranet, and these were being very successfully used instead of the approved corporate tools. So Corporate Central does a software evaluation exercise, buys an enterprise wide wiki product license and gets a

contractor to install it. An edict is sent out saying

that all wild wikis must move onto the corporate wiki farm and henceforth only the corporate wiki product should be used. So what happened next?

  • The corporate wiki had lots of nice features and some neat tools to help migrate onto it so quite quckly wikis migrated onto their own wiki nodes on the wiki farm.
  • Then the trouble started. Firstly the sysadmin person was only doing the role as a kind of a hobby - there wasn't any dedicated resource to keep pace with escalating demands for wikis. Wikis were the new tomorrow, everyone wanted one.
  • Suddenly wiki performance ground to a halt as all these new wikis started flogging the server. By this time there was a full time sysadmin, and althougth the wiki farm was on a highly scalable virtual server, the sysadmin could not get the sysops to allocate more server resources as there was not enough budget in the budget code to which to charge the costs.
  • Users are screaming at the sysadmin, who by now has run for the hills, so one of my colleagues took it as a personal challenge to sort it out - which he did after a couple of months. Got a full time sysadmin team, enough budget to support the servers the remainder of the year. Everyone was happy again.
  • Then the Security Directorate took an interest. They went apoplectic when they discovered that

    anybody could edit

    any page or even

    add new pages. So they ordered the sysadmins to turn off these features. Goodbye wikis ....

It eventually all got sorted out, but many previously happy people, spit when they hear the word, wiki. I suppose, if there is a moral here, it is beware unnecessary corporate control. What was a quite successful community of open source

wikis being run for little cost,

suddenly morphed into a multi-million pound project, managed by corporate edict, and by people who missed the fundamental idea behind a wiki. What's the Hawaiian for cock-up?

I've had a career in the IT business for over 35 years. I've covered many roles from Developer through to Lead Enterprise Architect. At heart I'm a techy with both software (30 years coding - I started with BASIC and COBOL!) and some front end design skills. I've worked on web stuff since 1993/94 and built some terrible web sites using Mosaic, early Netscape, and IE. Having left a large corporate, I've hung up my Enterprise Architect's hat and set up my own business, doing what I love best - building web sites. I've got HTML, CSS, Javascript, and PHP skills - I'm now getting on board with standards based design and learning all the time... and hopefully building better web sites than I used to in the early days

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.