IT wikis: why don't they work?

Wikis are now just as much a part of a company as punches and folders. They are a useful and important support for many departments. So why don't they work in the IT area? In this article, we look at when using wikis makes sense and when it doesn't.

When does it make sense to use a wiki?

Wikis are simple CMS systems in which users can collaboratively maintain information. This makes a lot of sense in the content of knowledge management. With one caveat: For the wiki to work and add value, you should only store certain types of information in it.

This means basic information such as:

• How-Tos ensure that teams and employees have all the information they need to be able to work. New colleagues especially benefit from them, as they can use them to learn how the company implements certain standards. This also includes instructions on how to set up a development environment correctly.
• Links, which are frequently required and important and which do not change very often should be collected in the wiki so that team members do not have to search for them for a long time. This also includes links to build systems and code repositories.
• Operating instructions that are valid for longer periods of time are also part of the basic information. These include backup and restore instructions.
• Operating concepts provide a sound basis for company decisions and are stable over a long period of time.
• Rules and guidelines should also be clear for everyone and always accessible.

What do all basic information have in common? They often form the basis for more in-depth knowledge, i.e., they represent the foundation that is stable over time and is rarely changed.

This information makes a wiki very valuable and makes it easier to share this knowledge with new colleagues. So, it seems tempting to extend this useful tool to other types of knowledge as well. But does that make sense?

What are the limits of IT wikis?

As you did read in our previous article, IT knowledge is very fast-moving. This means that the moment you put it on paper or in the wiki, it is often already out of date.

On the one hand, this has to do with the fact that it takes a lot of time to write down IT knowledge. The process of detailing can take as much time as the prior development based on the developer’s knowledge. Since this knowledge is also highly specific, it can simply be wrong for new situations. After all, every challenge when developing or operating software is somewhat different from the previous one. Plus, it takes only one implementation or interface to change for everything entered in the wiki to become obsolete.

This means that the effort involved in transferring knowledge to a wiki is many times higher than the actual development effort. In addition, it cannot be guaranteed how long this knowledge will remain correct. And outdated knowledge can be very dangerous.

So how useful is such documentation in the wiki? The question no longer arises after the above-mentioned version. And the Agile Manifesto already stated 20 years ago: "We prefer … working software over comprehensive documentation".

In a nutshell, the team should devote their capacity to making software that works, rather than wasting their time on comprehensive documentation that will be outdated in a moment.

The question is not where in the wiki is the knowledge required for a specific development to be found, but: where to find the colleague who can contribute his knowledge and experience to this development. And you can easily find this via 8Buddy via his skills. This shows once again that knowledge is not stored anywhere but is always tied to an employee.

Conclusion

Wikis are very useful and helpful provided they are used for managing and sharing basic information. IT knowledge, on the other hand, has a very short lifespan and is also tied to people. The effort to bring this knowledge into a wiki would be in vain, because it outdates quickly, and the effort far exceeds the benefit. So: why bother?

The truth is in the code.

teaser image licensed by CC BY-SA 2.0