這篇寫的蠻清楚的!

我用比較白話的說法。

接近於防呆理論及合理化條件。
雖然我說的很簡單。

實際上來說，這個定律要講的是一種很深遠的函義。
它還包含了習慣性及廣泛性。

這不止在it界上，商場及工廠內。都有其定律存在而不自知。

這個定律來說，我個人認為比較偏向精神面或人格主觀意識的說法。
如「自主性加班」「正職責任制」...等等。
都可以看到這些定律的影子存在。

總之...它就只是一種定律學說。就程式界而言來說。
我會比較偏向於防呆機制的應用說法。
用在資料庫的條件上。你不可能有 where id=1 AND id=2
這樣的用法。這我們一看就知道，再id是唯一值的情況下。
這樣的條件保証拿不到任何資料。
所以，你在設計上會變成理所當然的id條件得要唯一性。
而這個「理所當然」。就是這個定律要說明的意思。

雖然是一年前的文，可能原po已經不在乎了，還是來說說我的看法xDDD

先貼官網的 TL;DR

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.

簡單翻譯是

當某個 API 有足夠多的使用者
不論你在文件中如何解釋
所有可見的行為
終將被某個人所依賴

聽起來有點抽象
舉個例子

假如需要實作一個 debug printer，用來把簡單 struct 內部的值都印出來
於是你寫了一個函數

/// Print all values in `SomeStruct`, separated by comma.
void DebugPrint (SomeStruct ss) {
    const char* delimiter = ", ";
    // print
}

內容很簡單，就是把所有值印出來
並用一個逗號 + 一個半形空白來分隔

一開始大家都用得很愉快
漸漸地，DebugPrint 變得越來越多人用，因為它簡單又方便

有一天你突然想要把半形空白刪掉
簡單，30 秒完成
2 分鐘後卻有數十個人來抱怨說程式碼出錯了

這就是 Hyrum's Law 在講的問題

程式碼中清楚寫了分隔符號就是 ", "，這就產生了一個 observable behavior
即便作者從來沒有保證過不會更改分隔符號，甚至隻字未提半形空白
一定有一個人，或數十個人，會假設 DebugPrint 的分隔符號就是 ", "
而他們的程式碼，更可能會建立在這個假設之上實作

一但半形空白被刪掉，只剩下 ","，這些程式碼就會出錯

此時的唯二解，就是 1. 修正所有程式碼，或是 2. 把半形空白加回去，並永遠不再變更

而最好的方法，是從一開始實作的時候就避免這個問題
也就是不要使用固定數量的空白
如此一來可以確保使用者的程式碼不依賴半型空白的個數
又同時不違背註解

/// Print all values in `SomeStruct`, separated by comma.
void DebugPrint (SomeStruct ss) {
    bool jitter = ...; // some randomized boolean variable
    const char* delimiter = jitter ? ", " : ",  ";
    // print
}

簡單的說, 越多人用你的API, 越高機率程式依賴它的可觀測行為,即使該行為不在API的定義中.

例子:終會有程式依靠一個hash funtion傳回的固定序列順續. 即使hash function從未承諾傳回特定順續.