Continuous documentation

Borrowed from continuous integration

Continuous integration made merging code a routine event instead of a dreaded one: integrate often, and each integration is small enough to get right. Continuous documentation applies the same idea to docs. If documentation is brought up to date with every release, each update is small. If it waits for a rewrite, the gap is months of change at once.

What it changes

• The trigger. Documentation updates because the code changed, not because someone happened to notice a page was wrong.
• The check. Accuracy and coverage are measured every release, so a new error shows up in the release that introduced it.
• The cost curve. Drift is caught while it is one changed default, not after it has compounded into a page nobody trusts.

What it requires

Three things, whatever the tooling:

• A way to know which documentation a code change affects, so updates aren't all-or-nothing
• A recurring measurement, so the team can see whether docs are keeping up
• An owner for the findings, because a check nobody acts on is a report nobody reads

What it isn't

It isn't the same as docs as code. Docs as code puts documentation in version control and a build pipeline; continuous documentation is about cadence — keeping it current with every change. Docs as code makes that easier, but docs can sit in a repository and still go a year without an update.

Nor does it mean regenerating everything blindly. Human corrections and the explanations only people can write have to survive each update, or the process destroys the parts of the docs that were most valuable.