---
title: "The Need for Constant Updates (Wikis)"
date: 2012-06-12
description: "My journey to and from wikis   1.0 My Journey To and From Wikis: Why I Adopted Wikis, Why..."
canonical_url: https://idratherbewriting.com/2012/06/12/the-need-for-constant-updates-wikis/
---
# The Need for Constant Updates (Wikis)
Agile software methodology is a method of creating software in small releases to get feedback that helps inform the next release – proceeding to build the final product little by little based on iterative feedback rather than spending two years in seclusion working from a list of requirements that are out of date once you finally release.

We released a new version of the software every month, sometimes every two weeks. As such, the documentation was continually evolving. I began to follow a more agile writing process. As I participated in training for new users, it would always surprise me that no matter how well I described tasks and processes in the documentation, users had questions. They used the application in ways I didn't fully anticipate. Terms confused them. Step sequences were not easy to follow. They couldn't find information. Some tasks needed to be more visible. Who could anticipate all of this beforehand? As much as I tried, the documentation always needed adjustment.

Based on the feedback from training users, I changed the documentation, making it better and better with each released version.

![Documentation should be updated continually](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/infinity600.png)

I even hosted my documentation on a separate server so that I could update documentation on the fly. I wrote about this in a post titled [Two Stories About How to Write Help](https://idratherbewriting.com/2009/05/02/two-stories-about-how-to-write-help/). This iterative authoring approach seemed to align perfectly with agile software methodology; it presented a fundamentally different philosophy about how to approach help.

The traditional method of help authoring is to think you can write all the help you need *before* the application is released. The assumption is that the writer can anticipate all the user's concerns and needs, and so basically you're done once you release. You can move on to another project.