Content Reuse: Is It Harmful?

By Richard Hamilton, special to The Content Wrangler

A place for everything and everything in its place—Isabella Mary Beeton, The Book of Household Management, 1861

For a number of years it has been a matter of faith that the more content a technical documentation team reuses, the more efficient they are presumed to be. Vasont Systems, a content management system (CMS) vendor, claims its users average 71% content reuse. That is a bold claim, but I suspect that if you could show even 30% or 40% content reuse, you would earn bonus brownie points with nearly any manager. But, are you really more efficient? Let’s take a deeper look.

Terminology

Duplication: You separately maintain more than one copy of some piece of content in source control or a Content Management System (CMS). If you keep two copies of a glossary definition in your source control system, that would be duplication.
Reuse: You put the same piece of content into more than one deliverable in the same output medium. If you have just one copy of that glossary definition in source control, but include it in the printed versions of your Installation Guide and User’s Guide, that would be reuse.
Single sourcing: You deliver the same piece of content via different media. If you deliver the Installation Guide in print and also on the web, that would be single sourcing.

[Note: Any given piece of content can be reused or single sourced or both. Defining single sourcing and reuse separately may seem to be nitpicking, but the distinction is important.]

Why Minimize Reuse?

I doubt anyone would argue against minimizing duplication. The benefits are clear and the exceptions are relatively few. I also agree wholeheartedly that single sourcing makes very good sense. But, I differ with the mainstream regarding reuse. I believe you should minimize reuse, not maximize it.

There are two main reasons for minimizing reuse:

Every time you reuse content, you give your users another place to look at when they search for that topic. If you have the same content in several different places, your users can end up jumping around among those places, trying to figure out which one they should use. Having one, authoritative place for any particular module will simplify their search and avoid confusion.
Even with highly structured methodologies, reuse is not free. When you reuse content, you need to take steps to be sure that content will work in multiple locations. This takes effort that might not need to be expended for content that is not reused

Driving out Duplication

Most efforts to maximize reuse start by looking for and driving out duplication. The search for duplication typically identifies places where there is an exact or close match between two or more pieces of content. For each of those matches, you have three choices:

Continue to maintain two (or more) versions of the content.
Merge the matching content into one version, store that version in source control, and use it in each of the original locations as you build deliverables.
Remove all but one instance of the content, and if you must, point to it rather than copy it.

All three of these choices cost something. Choice one abandons reuse, giving you more content to maintain. That is not always a bad choice; if there are enough differences in the content to make maintaining one version more expensive than maintaining two versions, this might be a valid option.

Choice two is classic reuse; you will have some additional work making the module work in multiple contexts, and you will have some additional work over time maintaining that independence. But, you will usually save effort over maintaining separate versions.

Choice three eliminates duplication and reuse. If you can eliminate all but one of the situations that used the content, you have not only eliminated the duplication, you have reduced the overall size of your deliverables. When it works, this choice is the most efficient of the three.

The Bias Towards Maximizing Reuse

I see a bias towards choice two in most of what I have read about content reuse; in fact, often choice three is nowhere in sight. While structure is given its due, I see little discussion about structuring content to minimize the need for reuse. Several factors fuel this bias:

Metrics: It is easier to create a metric to measure reuse than it is to create one to measure where you have avoided the need to reuse.
Human nature: Choice three requires you to eliminate content. Since nearly all content was originally generated because someone needed it, your natural inclination will be to keep content, even if it is redundant.
Content Management Systems: The typical CMS makes reuse easy. Just mix and match modules, push a button, and poof, you have a new deliverable.
Structure: Choice three requires you to look more deeply into your structure, which your team may not have the time or inclination to do.

If unchecked, these biases can leave you with a lot of unnecessary reuse. You can argue that’s not a big deal, but even when well structured, a heavily reused module will take more maintenance than one that is used in just one place. In addition, it will needlessly increase the bulk of your deliverables. Both of these factors decrease efficiency. If you are serious about maximizing your efficiency, you need to structure your documentation with a bias against both duplication and reuse.

Implications for Modular Documentation

So, am I arguing against modular documentation? No. Consistent structure and style help people use your documentation. And good methodologies give your authors the guidelines they need to produce consistent structure and style. Where things go off the rails is when you try to treat your documentation as a set of modules that can be indiscriminately mixed and matched to create whatever deliverables you want.

Content that is central to your message deserves a context within which it can live. If it is pulled out of context, it will either be confusing, or it will require additional information to provide that context, either as part of the module itself, or in the including document.

Jon Bosak summed up the problem nicely in his Closing Keynote at the XML 2006 conference:

Another ancient subject that seems to be popping up again is the idea of modular document creation. This is one of those concepts that comes through about once a decade, seduces all the writing managers with the prospect of greater efficiency, takes over entire writing departments for a couple of years, and then falls out of favor as people finally realize that document reuse is not a solvable problem in document delivery but rather an intractable problem in document writing – which is, how to retain any sense of logical connection between pieces of information while writing as if your target audience consisted entirely of people afflicted with ADD.

While I do not have quite as pessimistic a view of modular documentation as Bosak expresses here, I do think that maximizing reuse without considering context and structure yields documentation that is difficult to use. Even if your structure allows you to easily reuse modules, there is benefit in doing so only when you have a compelling reason.

What I advocate is to first build a structure that minimizes the need to reuse content, then judiciously choose where, within that structure, you will reuse. Obvious cases include glossary entries, legal boilerplate, and repeated procedures. And you will find other places where it simply makes sense to include content rather than sending the user off somewhere else to find it.

If you start with Isabella Beeton’s words in mind, you will end up with less reuse, better structured documentation, a more efficient process, and maybe customers who do not feel you are inflicting ADD upon them.

About the Author
Richard Hamilton is principal consultant with R.L. Hamilton & Associates, specializing in documentation management and the application of XML technology to documentation. He is the author of the forthcoming book, Managing Writers: A Real World Guide to Managing Technical Documentation, which will be published by XML Press later this year.