Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyrum's Law

hyrumslaw.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: Hyrum's Law

#51

Post by kallyaleksiev »

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

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

Re: Hyrum's Law

#52

Post by kookamamie »

yau8edq12i wrote: post #48
pkasting wrote: post #39

Earlier quoted context omitted.

Titus Winters is actually the person who named this "Hyrum's Law" and popularized it as such.

Hyrum still made a website called "Hyrum's Law." That's just graceless, at best.

My thoughts, exactly. A law, really? A domain dedicated for this? Seems someone really wants their name in the CS history books.

Re: Hyrum's Law

#54

Post by pflenker »

cpeterso wrote: post #2

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?

I 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.

Re: Hyrum's Law

#56

Post by angiosperm »

codeflo wrote: post #41

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. 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 s…

It is the difference between CS and Engineering, and why I favor hiring engineers.

Re: Hyrum's Law

#57

Post by medler »

yau8edq12i wrote: post #48
pkasting wrote: post #39

Earlier quoted context omitted.

Titus Winters is actually the person who named this "Hyrum's Law" and popularized it as such.

Hyrum still made a website called "Hyrum's Law." That's just graceless, at best.

This 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/Say%27s_law https://en.wikipedia.org/wiki/Gresham%27s_law

Re: Hyrum's Law

#58

Post by tialaramex »

mjw1007 wrote: post #45
codeflo wrote: post #41

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. 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 s…

Yes, 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).

Yeah, no, humans can't hold complicated documentation in their heads. The whole experience of being human is finding a way to get by with a simple model which fits in your head but isn't wrong enough to cause trouble, and that's exactly what Hyrum is reflecting.

What you're getting at is the C++ "Just don't make any mistakes" approach to software engineering, which is a disaster that has cost our civilisation a great deal.

Re: Hyrum's Law

#60

Post by mjw1007 »

tialaramex wrote: post #58
mjw1007 wrote: post #45

Earlier quoted context omitted.

Yes, 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).

Yeah, no, humans can't hold complicated documentation in their heads. The whole experience of being human is finding a way to get by with a simple model which fits in your head but isn't wrong enough to cause trouble, and that's exactly what Hyrum is reflecting. What you're getting at is the C++ "Just don't make any mistakes" approach to software engineering, which is a disaster that has cost our civilisation a great…

That is emphatically not what I am "getting at". I cannot express my opposition to that approach strongly enough.

I do not believe that the place people should hold documentation is "in their heads".

I do not believe that Hyrum's "Law" is helpful in getting to a situation where people's beliefs about what software will do match reality.

This isn't the first time I've come across people (particularly around the Rust community) who have got the idea into their heads that saying "reading documentation is important" is somehow close to saying "Real programmers don't make mistakes". I think that conflation is doing great harm.

Post reply on HN