Does DRY (Don't Repeat Yourself) Apply to Documentation?
In programming, it's usually accepted that DRY code is better code in most situations.
Does this principle also apply to documentation?
I'm asking about the documentation output, not necessarily the source material (there are tools for keeping the source content DRY even if there's a lot of repeated content).
Example: suppose I have the following content:
- Some task
- Prerequisite setup task
- How to do X
- How to do Y
Should "How to do X" and "How to do Y" explicitly say "Before doing this, make sure to do Prerequisite setup task"? What are some good rules to follow when deciding if documentation should repeat itself?
I intended this question to be about end-user documentation. In some context, such as code or compliance documentation, the answer may drastically change. See Chenmunka's answer for some of those implications.
This post was sourced from https://writers.stackexchange.com/q/33529. It is licensed under CC BY-SA 3.0.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
The more your documentation is aimed at people reading it like a book the less you should repeat yourself. The more your documentation is a look at this one page read it put it away the more you should repeat yourself.
The most concrete example I can think of are aviation emergency checklists. No Co-Pilot is ever required to look anywhere else after he opened the correct check list. Everything is on that one page. Even if it's a step that is on half the pages (think inform tower), if it's deemed important enough to be there it's on every check list.
Since you apparently use automated documentation I'd say few repetitions in the user training guide but repeat yourself a lot in the emergency recovery runbook.
This post was sourced from https://writers.stackexchange.com/a/33531. It is licensed under CC BY-SA 3.0.
0 comment threads
I would say that most of the time it does not apply.
Suppose you are to document the use of one particular function. Good source code documentation instantly tells the user how to use that one function.
Now suppose a nearly identical function with nearly identical use exists. Bad documentation says "it works just like function x except..." and then sends the reader chasing the documentation of some other function that they aren't even using. Good documentation shouldn't force the reader to go look for information in multiple places in order to piece together the complete documented use.
To make an example of extremely bad documentation, take for example the C language ISO 9899 standard where we want to look up a very commonly used feature called "operator precedence". All it says is this:
The grouping of operators and operands is indicated by the syntax. 85)
Without any of the mentioned syntax listed. We are instead first sent to read a cryptic foot note 85), which in turn tells us to go read the syntax in each and every sub-chapter, a total of 17 chapters. The information we need is literally scattered in 17 different places of the document.
While they could just have summarized it with a simple table similar to this. Does this repeat what is said in each of the 17 chapters? Yes. But with the aid of such a table we now have useful documentation instead of utter crap.
Do repeat yourself in the form of a summary, please!
Depending on what you mean to document however, you could perhaps be smart about it and place all documentation of nearly identical functions in the same place. One example is man strcmp from the Unix manual, which lists the documentation for two similar functions strcmp and strncmp in the very same place. And now they suddenly get away with writing
The
strncmp()function is similar, except...
because all the information is easily found in one place, on that page the user is already reading.
0 comment threads
No. Don't repeat yourself is a good content management rule, which is what it is in programming as well. If you have two instances of the same thing it becomes harder to manage them. If it were not for the management issues it raises, there would be no point to the DRY doctrine.
But the same pieces of information is often needed in more than one place. Programming handles this by a function call. Functions exist so that a piece of code that performs a useful function can be used in many places. That code is, in fact, repeated, it is simply repeated at run time, rather than write time.
The equivalent of run time for documentation is read time. Just as the same function needs to be repeated many times at runtime in software, the same information needs to be repeated many times at read time in documentation.
This is why some documentation tools have elaborate content reuse systems: to enable content that occurs once at write time to occur many times at read time.
The reason that the same information needs to occur many times across a documentation set (or multiple documentation sets, if you have more than one product or version) is that people do not read the whole documentation set at once (or ever), they dip into it opportunistically when they need something, particularly when they are stuck on some operation. They are only going to read a small portion of the documentation set at any given time. For them, the topic or page that they find is the documentation set. (I call this, Every Page is Page One.) That page needs to have the information they need to complete their task. It can link to related material where needed, but there is still going to be a lot of repetition necessary to create usable docs.
0 comment threads
0 comment threads