Thread by @sarahmei

Hey do you need any more examples of how software development is like writing instead of like math? Because I got a great one for you.

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.

Single responsibility principle anyone?

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.

Those two situations now need to evolve their usage of that fragment at the same pace and in the same direction. Otherwise you get ...

CONDITIONALS.

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.

I'M SURE NOBODY HERE HAS ANY EXPERIENCE WITH A CODEBASE LIKE THAT

NO

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

In summary (because I must log off and go hound my kids to do homework and take showers), writing at scale runs into EXACTLY the same issues that software development at scale does. The concepts are represented by prose, instead of code, but the rest is the same.