首页
14 条评论
cpeterso超过 1 年前
One 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: <a href="https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-the-web-moving/" rel="nofollow">https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-...</a><p>What are other approaches?
评论 #39405365 未加载
评论 #39405708 未加载
评论 #39406640 未加载
评论 #39410622 未加载
评论 #39405316 未加载
评论 #39406613 未加载
评论 #39405228 未加载
评论 #39405277 未加载
kleton超过 1 年前
__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED<p><a href="https://github.com/facebook/react/blob/6a44f352ecdfa93949cade1d2e74755e7d7e9aaa/packages/react/index.js#L32">https://github.com/facebook/react/blob/6a44f352ecdfa93949cad...</a>
评论 #39409734 未加载
评论 #39411492 未加载
评论 #39408365 未加载
dang超过 1 年前
Related:<p><i>Git archive generation meets Hyrum's law</i> - <a href="https://news.ycombinator.com/item?id=34631275">https://news.ycombinator.com/item?id=34631275</a> - Feb 2023 (76 comments)<p><i>Hyrum's Law</i> - <a href="https://news.ycombinator.com/item?id=33283849">https://news.ycombinator.com/item?id=33283849</a> - Oct 2022 (53 comments)<p><i>Hyrum's Law</i> - <a href="https://news.ycombinator.com/item?id=29848295">https://news.ycombinator.com/item?id=29848295</a> - Jan 2022 (36 comments)<p><i>Hyrum's Law</i> - <a href="https://news.ycombinator.com/item?id=27386818">https://news.ycombinator.com/item?id=27386818</a> - June 2021 (5 comments)<p><i>Hyrum's Law: An Observation on Software Engineering</i> - <a href="https://news.ycombinator.com/item?id=21515225">https://news.ycombinator.com/item?id=21515225</a> - Nov 2019 (6 comments)<p><i>Hyrum's Law</i> - <a href="https://news.ycombinator.com/item?id=19249199">https://news.ycombinator.com/item?id=19249199</a> - Feb 2019 (1 comment)
cpeterso超过 1 年前
What 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?
评论 #39406732 未加载
评论 #39405091 未加载
评论 #39405366 未加载
评论 #39408604 未加载
评论 #39405437 未加载
评论 #39407359 未加载
pimlottc超过 1 年前
This seems to be a restatement of POSIWID<p><a href="https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does" rel="nofollow">https://en.m.wikipedia.org/wiki/The_purpose_of_a_system_is_w...</a>
codeflo超过 1 年前
I'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.<p>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.<p>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, <i>obviously</i>.<p>This is fixed <i>by training engineers</i>. 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.<p>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.<p>And then people wonder why every existing piece of software needs a fully staffed team nowadays <i>just to keep it working</i>. 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.
评论 #39407734 未加载
评论 #39407908 未加载
评论 #39409033 未加载
leosanchez超过 1 年前
Another example of Hyrum's Law, at stripe: <a href="https://brandur.org/text" rel="nofollow">https://brandur.org/text</a>
yau8edq12i超过 1 年前
If I understand correctly, it's the actual guy named "Hyrum" who made this website called "Hyrum's law"...? Geez.
评论 #39407106 未加载
sebastianconcpt超过 1 年前
One 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.
评论 #39406016 未加载
kallyaleksiev超过 1 年前
feels 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<p>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)<p>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
nonethewiser超过 1 年前
My attempt to generalize it because i dont think it its only true of apis.<p>With enough consumers, all observable system behaviors will be relied upon, regardless of the promises made by the system provider.
tomrod超过 1 年前
Hyrum and I went to grad school together! Different programs but neighbors. Really enjoyed Sunday barbecues with the guy. He's whip smart.
andrewingram超过 1 年前
One 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.
fragmede超过 1 年前
<a href="https://xkcd.com/1172/" rel="nofollow">https://xkcd.com/1172/</a>
评论 #39405090 未加载