Sarah MeiVerified account

Large companies often have huge amounts of written documentation. Salesforce, for example, has docs for end users, potential customers, employees of all stripes, external developers, and literally dozens of other categories of people.

Most of these pieces of documentation (save maybe github READMEs, and even those sometimes) are written by professional writers. But at scale, their output can't be just unstructured documents, like, just like opening a word doc and typing.

What they're writing has to be structured - broken down into component parts. This is for a number of reasons, but the one most interesting to us is _reuse_. They need to use pieces of a document in multiple places.

And why do they want to reuse elements? 1. Because the same information needs to appear in multiple places - developer docs & internal docs, for example - but when it changes, they don't want to have to hunt down all the places it's referenced and change each one, one at a time.

But just like with code, reuse is not 100% good all the time. Every time you reuse something, you are creating a dependency between the two situations where you use it.

And just like with code, in a small codebase [doc set] with only a few developers [writers] on it, a conditional here & there is fine. But when you've got hundreds of developers [writers]...it stops working quick.

Any existing conditional will attract more conditionals, because humans are nothing if not pattern followers. And when you come into the file, it sure looks like the thing to do is reuse the fragment but add your exception/special handling to the list!

I'm sure there's a law already out there about conditionals attracting more conditionals. If not, it's now Mei's First Law

In a codebase that evolves over time, the trick to keeping it nimble is to constantly be re-evaluating, for every piece of the code you look at, whether the see-saw of reuse<--->duplication is leaning at exactly the right angle.

Turns out it's the same in a big doc set. And every now and then, it turns out, the folks who own these large doc sets need to re-evaluate what they call their "reuse strategy."

Otherwise, you end up with a big ball of mud for a docset, so fragile that you can't even really tell what the consequences of even a small change will be. This drastically reduces the speed with which _any_ docs can be produced.

My apologies to the professional writers reading this - a) this is like super 101-level and b) I am probably using mostly incorrect terms for things. I'm just excited about the similarities I discovered today :D