14

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.

migrated from techcomm.stackexchange.com Feb 20 '18 at 15:19

  • In my field of software documentation, yes. But mostly for frequently used intro paragraphs, common commands, branding, init scripts, and other variables like that. Then in this case it can help you as you can update something once in one place. The thing is figuring out how to get that repetition to work in a multitude of contexts… Then when it comes to tooling, there are different options to implement this. – ChrisChinchilla Feb 1 '18 at 12:29
13

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.

18

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.

  • 5
    +1 for context in which the documentation is used; in pressured situations like in-flight emergencies, people aren't going to flip back and forth between pages (or open up new tab after new tab in browsers) following "for procedure x, see section 1.2.3.4" references. – Myles Feb 1 '18 at 9:36
8

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.
1

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:

  1. 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.

  • Have you by any chance misunderstood or misinterpreted the question? You seem to be discussing code documentation rather than technical user documentation. – Iva Koevska Jan 31 '18 at 15:43
  • To be fair the original question does not at present actually specify end user documentation. "Task" implies end user but does not explicitly preclude programmatic "tasks." – Charles W Feb 1 '18 at 16:54
  • While I had user documentation in my when I wrote the question, I didn't specify. This answer is another (valid) way to look at the same problem in a difference context. – Scribblemacher Feb 6 '18 at 17:45
0

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.

  • 1
    "Easy to manage" doesn't always match up with the needs of the reader. Readers may be reluctant to "click away" from the page they're on, especially if they're not sure exactly what they'll get in so doing. – Fiona Hanington Feb 1 '18 at 17:15
  • This isn't solely based on being easier to manage for me, it saves customers who are already familiar with the basic steps having to re-read content and avoids the risk of them skimming and missing vital information. – Julia Wilson Feb 2 '18 at 8:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.