Software Engineering at Google¶
Winters, T., Manshreck, Tom, & Wright, H. (2020). Software Engineering at Google: Lessons Learned from Programming Over Time. O'Reilly Media.
Cited by¶
6 citations across 6 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Observable Surface Becomes Contract
- In software and API design, Hyrum's law names it explicitly: with sufficient users, every observable behaviour of an API becomes part of its effective contract.
This sourceStates Hyrum's Law: with a sufficient number of users of an API, it does not matter what you promise in the contract — all observable behaviors of your system will be depended on by somebody.
- In software and API design, Hyrum's law names it explicitly: with sufficient users, every observable behaviour of an API becomes part of its effective contract.
- Rhetorical Velocity
- The recomposition-meaning invariant bites hard in software — the effective meaning of an API is whatever callers actually rely on, not what the author intended, which is why "Hyrum's Law" (every observable behavior of an interface will eventually be depended upon by someone) is the engineering folk-statement of the prime's claim that recomposition, not authorial intent, arbiters meaning.
This sourceStates Hyrum's Law: 'With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody' — the engineering form of the recomposition-meaning invariant.
- The recomposition-meaning invariant bites hard in software — the effective meaning of an API is whatever callers actually rely on, not what the author intended, which is why "Hyrum's Law" (every observable behavior of an interface will eventually be depended upon by someone) is the engineering folk-statement of the prime's claim that recomposition, not authorial intent, arbiters meaning.
Domain-specific¶
- Hyrum's Law
- Hyrum's Law, formulated by Hyrum Wright and popularised in Winters, Manshreck, and Wright's Software Engineering at Google (2020), is the principle that with a sufficient number of users of an interface, it does not matter what is promised in the formal contract: every observable behaviour of the system will come to be depended upon by somebody, and any change to that observable behaviour — even one outside the documented specification — will break someone's code
This sourceThe remedy of proactively randomizing iteration order between library versions and runs so that no stable dependency on a particular order can form.
SupportedVerified against a saved copy of the source
“Software Engineering at Google”
- Hyrum's Law, formulated by Hyrum Wright and popularised in Winters, Manshreck, and Wright's Software Engineering at Google (2020), is the principle that with a sufficient number of users of an interface, it does not matter what is promised in the formal contract: every observable behaviour of the system will come to be depended upon by somebody, and any change to that observable behaviour — even one outside the documented specification — will break someone's code
Mechanisms¶
- API Version Sunset Policy
- The subtler trap is Hyrum's Law
This sourceStates that, with enough users, every observable behavior of a system will be depended on by somebody regardless of what the formal contract promises.
- The subtler trap is Hyrum's Law
- Backward Compatibility Policy
- Every promise kept is behaviour the new version must carry, and the burden grows: with enough dependents, every observable behaviour — including quirks and bugs no one meant to guarantee — becomes something someone relies on
This sourceStates Hyrum’s Law: every observable behavior can acquire dependents, increasing the burden of change.
- Every promise kept is behaviour the new version must carry, and the burden grows: with enough dependents, every observable behaviour — including quirks and bugs no one meant to guarantee — becomes something someone relies on
- Platform Semantic Versioning and Release Train
- And even a scrupulous, spec-correct change can break someone, because builders inevitably come to depend on observed behavior beyond the documented contract — Hyrum's Law.
This sourceStates Hyrum's Law: with enough users, observable behavior beyond the documented contract will acquire dependents, so even spec-correct changes can break users.
- And even a scrupulous, spec-correct change can break someone, because builders inevitably come to depend on observed behavior beyond the documented contract — Hyrum's Law.
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? Read against the text for 1 of 6 citations: 1 supported. Each verdict is shown under its citation below, with what in the work backs the sentence.
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.
Links previously used in the corpus¶
Before the registry existed this work was also linked 2 other ways.
- https://abseil.io/resources/swe-book ×2
- https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ ×2
Registry ID ref:edd7228a782e · see in the full table