Does DRY (Don't Repeat Yourself) Apply to Documentation?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

This largely depends on the output. If your output is a print book and is meant to be consumed as a book (as a whole, rather than piece by piece), DRY applies. If your output is a single print or digital page that can be consumed at a glance, DRY applies.

If you're working with online or digital content that is searchable and users are likely to land at it from any possible place (via search engines, via built-in search, via "jumpable" index), DRY does not apply.

In this case, as users are likely to end up on your page because they are looking for particular information or a particular problem solution, you want to provide all the relevant and important information in one place. So they can do their job and solve their problem. You don't want to reference them to yet another page or yet another section that drives them out of the current context. Basically, with this type of output, "repeat" in the following cases:

• The information is essential to the completion of the task. Skipping it (placing it somewhere else and expecting someone to read it separately) results in the user being unable to perform the task.
• The information is crucial to the safety and well-being of the reader. Skipping it (placing it somewhere else and expecting someone to read it separately) results in the user being harmed and suing you.
• The information is an integral part of the completion of the task. For example, a step, somewhere in the middle of the procedure, of clicking Next or OK, or performing something else. Or information about the required privileged access.

Answer 4

Yes it does.

You will be writing your code based upon a Software Requirements Specification. This will contain a series of numbered clauses in the form:

123. If x happens do y

These clauses will not repeat themselves as they must be uniquely testable and auditable. DRY most definitely applies in this part of the documentation.

So in your code documentation, you expect to see statements along the lines of:

Function x() satisfies requirement 123.

This gives you a one-to-one verifiable trace that the software has been written to do what it should do.

Any repetition, e.g.

Function x() satisfies requirement 123 but needs function y() which satisfies requirement 234.

leads to the possibility of confusion and later disagreement as to whether the software passes verification and validation. Also, many automated V&V tools will baulk at multiple references.

Obviously dependencies must be documented, but repetition should be avoided if possible.

The User Manual will, in many cases, refer to the Requirements Specification. Indeed in some cases, the Requirements Specification is the User Manual. The requirements are written from the point of view of the end user and the Requirements Specification is also used for training. This can be a contractual requirement in my experience. There too you will need to reduce the number of repetitions if possible.

Answer 5

I produce web based help - which is usually read on a per page basis, and have a DRY approach.

I'll usually just add a cross reference into steps, rather than repeating - as this is much easier to manage.