5 ms·

Hyrum's Law: An Observation on Software Engineering

rovek 7y ago
https://en.wikipedia.org/wiki/Murphy's_law#cite_ref-3 https://en.wikipedia.org/wiki/Murphy's_law#cite_ref-3
RcouF1uZ4gsC 7y ago
Raymond Chen’s blog the Old New Thing is a wonderful source of stories of programs relying on undocumented, internal behavior and the Herculean efforts Microsoft undertook to keep them working with new versions of Windows. Here is an example: https://devblogs.microsoft.com/oldnewthing/?p=41373 https://devblogs.microsoft.com/oldnewthing/?p=41373
voiper1 7y ago
Relevant XKCD, of course: https://xkcd.com/1172/ https://xkcd.com/1172/
lucas_membrane 7y ago
I believe you can restate this as: With a sufficient number of users, all bugs will eventually become features. I spent many years maintaining an old system with spaghetti-like structure and thousands of users. When attempting to design fixes to known problems I would often dig up odd code that looked like it could not possibly be correct. When I pointed out the odd behaviors that resulted from the suspect code to managers or other programmers somewhat familiar with the system, they just about always advised to never change anything just because it looked bad, no matter how bad. The question, "Bug or feature?" is meaningless in such a situation.
elipsey 7y ago
Sadly, the author forced the text layout to 1000 columns wider than my phone, so I cannot learn what Hyram's law is without scrolling from left to right until my thumb bleeds... Would anyone care to paraphrase it?
ncmncm 7y ago
There is a solution to Hyrum's Law: Change undocumented details on every release. If you have hash tables, change the hash function. Change offsets and placement of struct members. You can't change everything somebody might accidentally or foolishly depend on, and yes, some users' code will break, but the sooner it breaks, the less disruptive the bug revealed is. For many years, the maintainer of GNU libc refused to accept bug reports for behavior that wasn't documented, and gleefully broke undocumented behaviors that users had been so foolish as to rely on. As people were accustomed to this, it caused little actual difficulty, and gave enormous freedom to make improvements throughout the system, so the library continued to improve. Some people responded by copying the code they depended on into their own programs. OpenSSL was one such project, and the code they copied in, and the code that depended on incidental details of it, was a very fertile source of gaping security holes.

https://en.wikipedia.org/wiki/Murphy's_law#cite_ref-3 https://en.wikipedia.org/wiki/Murphy's_law#cite_ref-3

Raymond Chen’s blog the Old New Thing is a wonderful source of stories of programs relying on undocumented, internal behavior and the Herculean efforts Microsoft undertook to keep them working with new versions of Windows. Here is an example: https://devblogs.microsoft.com/oldnewthing/?p=41373 https://devblogs.microsoft.com/oldnewthing/?p=41373

voiper1 7y ago

Relevant XKCD, of course: https://xkcd.com/1172/ https://xkcd.com/1172/

lucas_membrane 7y ago

I believe you can restate this as: With a sufficient number of users, all bugs will eventually become features. I spent many years maintaining an old system with spaghetti-like structure and thousands of users. When attempting to design fixes to known problems I would often dig up odd code that looked like it could not possibly be correct. When I pointed out the odd behaviors that resulted from the suspect code to managers or other programmers somewhat familiar with the system, they just about always advised to never change anything just because it looked bad, no matter how bad. The question, "Bug or feature?" is meaningless in such a situation.

elipsey 7y ago

Sadly, the author forced the text layout to 1000 columns wider than my phone, so I cannot learn what Hyram's law is without scrolling from left to right until my thumb bleeds... Would anyone care to paraphrase it?

ncmncm 7y ago

There is a solution to Hyrum's Law: Change undocumented details on every release. If you have hash tables, change the hash function. Change offsets and placement of struct members. You can't change everything somebody might accidentally or foolishly depend on, and yes, some users' code will break, but the sooner it breaks, the less disruptive the bug revealed is. For many years, the maintainer of GNU libc refused to accept bug reports for behavior that wasn't documented, and gleefully broke undocumented behaviors that users had been so foolish as to rely on. As people were accustomed to this, it caused little actual difficulty, and gave enormous freedom to make improvements throughout the system, so the library continued to improve. Some people responded by copying the code they depended on into their own programs. OpenSSL was one such project, and the code they copied in, and the code that depended on incidental details of it, was a very fertile source of gaping security holes.