Documentation Decay
The tendency of written documentation to become inaccurate faster than it is updated, making stale documentation actively more harmful than none.
Wrong documentation is worse than missing documentation, because it is trusted. A reader who finds nothing investigates; a reader who finds a confident, outdated description acts on it.
Decay is not a discipline problem to be solved by exhortation. It is a structural property of documents that are separate from the thing they describe, and the remedies are structural too:
Generate what can be generated — API reference from specifications, deployment diagrams from infrastructure-as-code, dependency graphs from build files. Generated documentation cannot go stale.
Co-locate the rest with the code, versioned together, so it appears in the diff when the code changes. A wiki page in a separate system will not be updated.
Write the durable things and not the volatile ones. Why a decision was made ages well; a list of configuration values does not. Documentation that records reasoning has a much longer half-life than documentation that records state.
Date and own everything. A page with a date and a name can be judged; an anonymous undated page cannot.
Delete aggressively. A smaller accurate set beats a large stale one, and deletion is the maintenance activity nobody schedules.
The test worth applying periodically: pick three documents at random and check them. The result is usually a persuasive argument for the practices above.