7 ms·
Hyrum's Law
- cpeterso 3y agoWhat are some fun or unusual examples of Hyrum’s Law that you’ve run into? Were you the user, inadvertently depending on some implementation detail? Or were users depending on your implementation’s details?
- malkia 3y agoI think Windows is the epitome of following Hyrum's Law decades before Hyrum's Law came into being :) https://twitter.com/pwnallthethings/status/1363260064929362047 https://twitter.com/pwnallthethings/status/13632600649293620... I guess the linux kernel still supprorting binaries from ages ago might be too.
- LoganDark 3y ago> I guess the linux kernel still supprorting binaries from ages ago might be too. Actually it's Linus making sure that kernel changes don't break old binaries from ages ago. And in fact there were many cases of undocumented behavior being relied on by apps, and Linus would send big rants about how you never break userspace, whether the behavior is documented or not. Don't have any of them on hand right now, unfortunately.
- wrsh07 3y agoAt Google (long time off and on home of Hyrum), they migrated to swisstable from other hash maps. Unordered map iterates through the elements in insertion order. They explicitly couldn't support that without adding overhead to their new table so they randomized iteration order of the map The migrations to the new table were fun because you would migrate some code and then find a test that assumed the order things were inserted into some seemingly distant protocol buffer array were in insertion order of the map Usually the ordering was just a defect of the test, but it required actually digging in to be sure
- deleted 3y ago[deleted]
- tialaramex 3y agoIIRC There's a (CppCon?) talk about this rollout where Hyrum is in the audience so that he can heckle each time they describe a change which "obviously" can't break anybody because of course Hyrum's Law did cause that to break at Google when they did it. Maybe somebody who remembers better can link it and/or correct my memory of exactly what's going on.
- vitus 3y agoI believe it's this talk on swisstables from cppcon 2019: https://youtu.be/JZE3_0qvrMg?t=1426 https://youtu.be/JZE3_0qvrMg?t=1426
- david_allison 3y agoI implemented a development-only feature which span up a thread and permanently held a lock on the database, effectively making the app useless until restarted. A couple months later, I had a user thank me for it. I still don't know why
- havermeyer 3y agoI reviewed a CL from Hyrum at Google where he was trying to remove a `set_timeout(float)` method in favor of `set_timeout(absl::Duration)` and changed the former to delegate to the latter. It turned out that there was some special handling of inf/nan in the legacy API, despite no mention in the documentation, and his CL broke a number of tests. It was amusing to experience Hyrum's law so directly :)
- NlightNFotis 3y agoLove this! I was just reading the book and I came across this now, haha :)
- quectophoton 3y agoLet's just say "this HTTP endpoint expects its body to be JSON" and "we use a library that allows invalid JSON" (e.g. trailing commas) aren't exactly a good combination. Code easily ends up depending on the specific library's quirks and config, regardless of what the actual contract said.
- pflenker 3y agoI joined a company once where some APIS were, for some reasons, returning strings instead of booleans (e.g. "false" instead of _false_). One of the system returned a typo for some edge cases, e.g. "ture" instead of "true". But instead of fixing this, other systems relied on the typo to be returned, so it was difficult to just fix the typo and move on. Needless to say I didn't stick around.
- cpeterso 3y agoOne approach to guard against Hyrum’s Law is GREASE (aka “Generate Random Extensions And Sustain Extensibility” used in the TLS 1.3 protocol) i.e. behavior randomization to avoid inadvertent dependencies on unspecified behavior: https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-the-web-moving/ https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-... What are other approaches?
- jackblemming 3y agoTelling people who depended on probably internal behavior that wasn’t an explicit part of your contract to fuck off when they whine about you changing something.
- salawat 3y agoYou don't get to decide what is and isn't an implementation detail. And lets be real. There is no contract, and any one that is made will inevitably be broken.
- kazinator 3y agoThat depends entirely on the economics of the situation. Like who violates the contract, and how much business they represent. Or other measure of their importance. Does the C library change break a major distro? Or just some obscure program with three users?
- summerlight 3y agoWhen the clients have the power (e.g. a team that contributes to 90% of company's revenue), breaking the contract is often non-option from the beginning.
- c0pium 3y agoAh yes, the “you’re holding it wrong” strategy.
- aaron695 3y ago> “Generate Random Extensions And Sustain Extensibility” This should get a re-submit on HN (0 comments - https://news.ycombinator.com/item?id=16149534 https://news.ycombinator.com/item?id=16149534 4 years ago) I wonder if it would allow for easter eggs again. Would the fabled story between Larry Osterman and Raymond Chen's Exchange POP3 server easter egg fall within GREASE - https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs https://learn.microsoft.com/en-us/archive/blogs/larryosterma...
- deleted 3y ago[deleted]
- fragmede 3y agohttps://xkcd.com/1172/ https://xkcd.com/1172/
- scubbo 3y agoYes, that is in the body of the article.
- andrewingram 3y agoOne could argue that React’s strict mode behaviour in dev is a guard against this —- as it prevented you from building things that will break with (the then) upcoming functionality.
- sebastianconcpt 3y agoOne thing I found surprising is how disregarding many companies are about creating and nurturing know-how transfer culture among teammates. They seem to value compartmentalisation so much that they forget they are not de-risking themselves from Bus Factor.
- erhaetherth 3y agoIn times of lay offs, a bus factor of 1 is preferable.
- jamestimmins 3y agoMany the engineer has found solace in this, only to learn they were on a project management didn’t actually care about.
- dang 3y agoRelated: Git archive generation meets Hyrum's law - https://news.ycombinator.com/item?id=34631275 https://news.ycombinator.com/item?id=34631275 - Feb 2023 (76 comments) Hyrum's Law - https://news.ycombinator.com/item?id=33283849 https://news.ycombinator.com/item?id=33283849 - Oct 2022 (53 comments) Hyrum's Law - https://news.ycombinator.com/item?id=29848295 https://news.ycombinator.com/item?id=29848295 - Jan 2022 (36 comments) Hyrum's Law - https://news.ycombinator.com/item?id=27386818 https://news.ycombinator.com/item?id=27386818 - June 2021 (5 comments) Hyrum's Law: An Observation on Software Engineering - https://news.ycombinator.com/item?id=21515225 https://news.ycombinator.com/item?id=21515225 - Nov 2019 (6 comments) Hyrum's Law - https://news.ycombinator.com/item?id=19249199 https://news.ycombinator.com/item?id=19249199 - Feb 2019 (1 comment)
- nonethewiser 3y agoMy attempt to generalize it because i dont think it its only true of apis. With enough consumers, all observable system behaviors will be relied upon, regardless of the promises made by the system provider.
- kleton 3y ago__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED https://github.com/facebook/react/blob/6a44f352ecdfa93949cade1d2e74755e7d7e9aaa/packages/react/index.js#L32 https://github.com/facebook/react/blob/6a44f352ecdfa93949cad...
- xen0 3y agoHope you like firing people.
- rcbdev 3y ago"its-fine" https://github.com/pmndrs/its-fine https://github.com/pmndrs/its-fine
- MichaelZuo 3y agoWhat would be the equivalent for an open source project?
- hskalin 3y agoBanned from contributing?
- tomrod 3y agoHyrum and I went to grad school together! Different programs but neighbors. Really enjoyed Sunday barbecues with the guy. He's whip smart.
- leosanchez 3y agoAnother example of Hyrum's Law, at stripe: https://brandur.org/text https://brandur.org/text
- yau8edq12i 3y agoIf I understand correctly, it's the actual guy named "Hyrum" who made this website called "Hyrum's law"...? Geez.
- pkasting 3y agoTitus Winters is actually the person who named this "Hyrum's Law" and popularized it as such.
- yau8edq12i 3y agoHyrum still made a website called "Hyrum's Law." That's just graceless, at best.
- TwentyPosts 3y agoEh. Someone named it after him, and the name stuck. It's a good concept. Why shouldn't he? What does it matter? Who's harmed by this?
- marliechiller 3y agoNoone has to be harmed for it to be graceless, its just an opinion
- kookamamie 3y agoMy thoughts, exactly. A law, really? A domain dedicated for this? Seems someone really wants their name in the CS history books.
- medler 3y agoThis is a common pattern in history: - Person 1 makes an observation that they assert is true - Person 2 refers to this observation as “Person 1’s Law” for convenience when discussing the observation and whether or not it is true. There’s nothing wrong or “graceless” with Person 1 then using the term themselves, even for the purpose of arguing in favor of their assertion (which is what this web page is doing). Some examples: https://en.wikipedia.org/wiki/Moore's_law https://en.wikipedia.org/wiki/Moore's_law https://en.wikipedia.org/wiki/Say%27s_law https://en.wikipedia.org/wiki/Say%27s_law https://en.wikipedia.org/wiki/Gresham%27s_law https://en.wikipedia.org/wiki/Gresham%27s_law
- codeflo 3y agoI'm not trying to be overly dramatic, but I think it's precisely when the industry accepted this as a law -- instead of treating it as something that needs be trained out of junior programmers -- is when software quality started to tank. Consider any other form of engineering. Take some kind of screw. It has a documented specification in terms of torque, material strength and whatnot. Good engineers on the customer side will use the screws in a way that keeps within the spec. And good engineers on the supplier side will find ways to fulfill that specification as cheaply (which usually also means as narrowly) as possible. There could be a kind of Hyrum's Law at play, if hardware engineers were idiots. Let's say that the screws accidentally overfulfil the specification today by 20%, and a customer measures the material to figure this out, and starts to depend on that. A year later, the supplier finds a cheaper way to produce the screws (or introduces a binning process) and as a consequence, the screws only exceed the spec by 5%, and the customer's product breaks. Who's responsible? The customer. And I should add, obviously. This is fixed by training engineers. No one in their right mind would start to introduce artificial faults into their screws purely for the reason to prevent users from depending on the excess strength or something. But that's exactly the kind of thing that's regularly suggested to guard against Hyrum's Law. So whenever I see software developers on my team look at the source code of a library to figure out "whether it's thread-safe" or "whether the sort order is stable" or whatever, I die a little on the inside. The problem is, you almost have to do that, because were two generations of software engineers into this and the practice is so accepted now that libraries no longer bother to document what they do (and don't) guarantee. And then people wonder why every existing piece of software needs a fully staffed team nowadays just to keep it working. And why as a consequence, even core products built by competent companies (like Google Maps) have regressions in 15-year-old features every other week.
- mjw1007 3y agoYes, the relationship between "Hyrum's Law" and having a terrible documentation culture is strong. The important part of the "Law" is the bit where it says "it does not matter what you promise in the contract". That's definitely going to be true in a place where neither writing nor reading documentation is taken seriously (and one of the main things this site teaches us is that Google is such a place).
- kallyaleksiev 3y agofeels like there's two slightly distinct phenomena that are interesting to point out -- implicit (or explicit) dependency on something that is actually true vs dependency on something that is not true in the latter case the client forms a dependency on observed service behaviour based on an incorrect assumption of a contract -- i.e. as with the Google Chubby service story -- so they end up getting burned when the server does not satisfy that (of course it's the developer's responsibility to prevent them from forming the dependency in the first place) the former is when clients form dependencies over assumptions that are actually correct but have not been intended to be observable, e.g. using some sort of nice library or data structure internally, then users starting to depend on that performance, making it hard for you to change the implementation
- pimlottc 3y agoThis seems to be a restatement of POSIWID https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_w...