alt Hacker NewsRemember this article when you get upset that your own customers have come to rely on behavior that you told them explicitly not to rely on.
If it is possible to figure something out, your customers will eventually figure it out and rely on it.
Remember this article when you get upset that your own customers have come to rely on behavior that you told them explicitly not to rely on.
If it is possible to figure something out, your customers will eventually figure it out and rely on it.
Once a system has a sufficient number of users, it no longer matters what you "explicitly" promised in your documentation or contract.
Hyrum’s Law: all observable behaviors of your system will eventually be depended on by someone.
Even if you tell users not to rely on a specific side effect, once they discover it exists and find it useful, that behavior becomes an implicit part of your system's interface. As a result, engineers often find that "every change breaks someone’s workflow," even when that change is technically a bug fix or a performance improvement.
Reliance on unpromised behavior is something I was also introduced to as Kranz’s Law (or Scrappy's Law*), which asserts that things eventually get used for their inherent properties and effects, without regard for their intended purpose.
"I insisted SIGUSR1 and SIGUSR2 be invented for BSD. People were grabbing system signals to mean what they needed them to mean for IPC, so that (for example) some programs that segfaulted would not coredump because SIGSEGV had been hijacked. This is a general principle — people will want to hijack any tools you build, so you have to design them to either be un-hijackable or to be hijacked cleanly. Those are your only choices." —Ken Arnold in The Art Of Unix Programming