Hyrum's Law: An Observation on Software Engineering¶
Wright, H. (2026). Hyrum's Law: An Observation on Software Engineering: An Observation on Software Engineering. hyrumslaw.com.
Cited by¶
11 citations across 11 artifacts.
Each citation links to the sentence it supports in the citing article.
Mechanisms¶
- Abstraction-Barrier Code Review
- This is precisely the accretion Hyrum's Law describes: with enough clients, every observable behavior eventually gets depended on unless someone holds the line.
This sourceHyrum's Law website (n.d.). States that with enough users of an API, every observable behavior of the system will be depended on by someone.
- This is precisely the accretion Hyrum's Law describes: with enough clients, every observable behavior eventually gets depended on unless someone holds the line.
- API or Integration Layer
- With enough consumers, every observable behavior — including accidental ones — gets depended upon, so nothing is safely changeable (informally, Hyrum's Law
This sourceStates that, with enough API users, every observable behavior and implementation detail will be depended on by somebody.
- With enough consumers, every observable behavior — including accidental ones — gets depended upon, so nothing is safely changeable (informally, Hyrum's Law
- API or RPC Endpoint
- With enough callers, every observable behavior — undocumented field ordering, incidental latency, the exact wording of an error — becomes something someone depends on, so the implementation you thought was hidden is quietly load-bearing.
This sourceStates that with enough API users every observable behavior acquires dependents, turning implementation details into a change-constraining implicit interface.
- With enough callers, every observable behavior — undocumented field ordering, incidental latency, the exact wording of an error — becomes something someone depends on, so the implementation you thought was hidden is quietly load-bearing.
- Backward Compatibility Test
- With enough consumers, every observable behavior ends up depended on by someone regardless of what the contract says, so a green backward-compatibility test bounds the known contract, never proves that nobody breaks.
This sourceWarns that widely used systems acquire dependencies on observable behavior beyond the formal contract.
- With enough consumers, every observable behavior ends up depended on by someone regardless of what the contract says, so a green backward-compatibility test bounds the known contract, never proves that nobody breaks.
- Changelog and Release Notes
- The discipline that keeps it honest is to log the change when you make it, always disclose breaking changes and security fixes, and never break silently — a habit sharpened by the reality that with enough downstream users, every observable behavior of the artifact has become something someone depends on
This sourceStates that with enough users, every observable behavior of a system will be depended on by somebody.
- The discipline that keeps it honest is to log the change when you make it, always disclose breaking changes and security fixes, and never break silently — a habit sharpened by the reality that with enough downstream users, every observable behavior of the artifact has become something someone depends on
- Channel Deprecation Notice
- And "nobody still uses this" is a famously unsafe assumption: with enough users, some depend on the channel in ways never advertised.
This sourceHyrum's Law warns that, with enough users, somebody will depend on every observable behavior, including behavior never promised in the documented contract.
- And "nobody still uses this" is a famously unsafe assumption: with enough users, some depend on the channel in ways never advertised.
- Compatibility Guarantee
- Its trap is that a broad, long compatibility guarantee can freeze the network's own evolution: promise too much stability and you inherit every behavior anyone came to depend on, so you can no longer change the thing you guaranteed.
This sourceHyrum's Law (nd). Observes that users eventually depend on every observable behavior, creating implicit interfaces that constrain implementation changes and system evolution.
- Its trap is that a broad, long compatibility guarantee can freeze the network's own evolution: promise too much stability and you inherit every behavior anyone came to depend on, so you can no longer change the thing you guaranteed.
- Deprecation Program
- Its failure mode is Hyrum's Law:
This sourceStates Hyrum's Law: with enough users, every observable behavior of a system will be depended on by someone.
- Its failure mode is Hyrum's Law:
- Interface Surface Reduction Review
- Its failure mode is the hazard that an exposed element with no obvious purpose may still have silent dependents: some integrator has wired against that odd field, and cutting it breaks them invisibly.
This sourceHyrum's Law warns that consumers depend on observable behavior, including undocumented details, so changing an apparently purposeless interface element can break unseen dependencies.
- Its failure mode is the hazard that an exposed element with no obvious purpose may still have silent dependents: some integrator has wired against that odd field, and cutting it breaks them invisibly.
- Schema or API Specification Publication
- Consumers inevitably come to depend on observable behaviors the spec never promised — Hyrum's Law — so a specification that drifts from what the artifact really does becomes a liability that integrators trusted.
This sourceStates that with enough API users, every observable system behavior will be depended on by someone regardless of what the contract promises.
- Consumers inevitably come to depend on observable behaviors the spec never promised — Hyrum's Law — so a specification that drifts from what the artifact really does becomes a liability that integrators trusted.
- Semantics-Preserving Refactoring
- The signature failure is a silent boundary violation — a "pure refactor" that changes an error message, an ordering, a timing, or an undocumented side effect some client depended on (with enough users, every observable behavior ends up depended on by someone).
This sourceWarns that an ostensibly internal refactor can break clients because every observable behavior, documented or not, may become a dependency.
- The signature failure is a silent boundary violation — a "pure refactor" that changes an error message, an ordering, a timing, or an undocumented side effect some client depended on (with enough users, every observable behavior ends up depended on by someone).
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 11 citations of this work carries a recorded support check.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:7e97a4edf67c · see in the full table