The term ​“Hyrum’s Law” was brought up in a tech standup meeting the other day. I think a developer said some customer had jerry-rigged our source code for some peculiar (and, only to my mind, evil) purpose. Then he said, ​“So, yeah — it’s basically a classic case of Hyrum’s Law.”

At the words ​“Hyrum’s Law,” everyone in the video call nodded, sagely. Everyone. From the founders on down to the new engineer. Ah, yes, Hyrum’s Law, they all thought. The law that we’re all quite, quite familiar with.

But I had no clue. Who the heck’s Hyrum? What’s his law? Hyrum? Rhymes with Fire ​’em? Hyrum and fire ​’em? Am I about to get canned? What’s going on? I clicked off my camera. Had they seen my blank stare? My open mouth? The sweat gushing down my forehead? In case they heard my heart beating against my ribcage, I switched off my mic.

Then something else was said, someone else was up, and a link to Hyrum’s Law was thrown into the chat. Hyrum was done. The tech standup continued.

(To define a tech standup meeting: one by one, people cite slight annoyances and overstate what they’re working on, while the rest check Slack.)

Undercover in the call, camera and mic shut down, I tried to get my bearings. When I heard the words ​“Hyrum’s Law,” I thought it was some ancient law testifying to some truth so true, so eternal, it speaks through the centuries. (From your chisel and lips, all the way to today’s software developers’ eyes and ears, your law is honored by us, and how were the Peloponnesian Wars, Wise Old Hyrum?)

Hans?
Huh?
Hans?
Me?
Hans!

It was my turn in the standup! I clicked on my camera and mic.

Then I:

• cleared my throat
• combed my hair using my fingers
• scrolled my Slack
• saw what I’d said the day before
• said that
• didn’t mention Hyrum
• forgot the alphabet
• remembered the alphabet
• passed it to the next guy in the alphabet
• killed my mic and camera again
• and slumped down on my desk.

The standup ended. I took a breath. I opened a tab. I searched for ​“Hyrum’s Law.”

Oh, God. How wrong I was.

Hyrum’s alive. He works at Google. He’s an alive guy.

Hyrum’s law, in his own words:

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.

As someone who appreciates poetry, I like that Hyrum formed his law into lyrics, four separate lines of free verse. (Formalists may prefer a rhyme scheme, and that’s asking too much.) But what does his law mean? Let’s go line by line. Line one:

With a sufficient number of users of an API

What Hyrum means here (I think) is that the number of users of an API must reach a threshold for the law to kick in. Fair enough. Now, what the hell’s an API?

I did a quick search (and granted my function of feeling shame a short stay of execution, since I work for a tech company and should have known what an API is before I tied my shoes to go to the interview). I found that API stands for Application Programming Interface. API, then, refers to any software handling requests and responses. A client’s involved, so’s a server, and so are applications, and maybe that’s about it.^*

Line two:

it does not matter what you promise in the contract

So Hyrum says here that your word means nothing. Despite what gangstas might say on the streets, in software, word, evidently, is not bond. It’s an interesting turn of events. Usually contractual language is necessarily binding. Here, though, Hyrum seems to say, meh. There’s wiggle room.

Putting the two first lines together, ​“With a sufficient number of users of an API, it does not matter what you promise in the contract.” As usage, or popularity, of your software rises, how you define your contract with the end user matters less. Again: interesting! Or is it?^**

Lines three and four:

all observable behaviors of your system
will be depended on by somebody.

This half of the law may sound eerily familiar to parents, and I think it applies especially to mothers. But in software, ​“observable behaviors of a system” signify something sterile. Providing a software system entails all sorts of things. Hyrum means that, whether you like it or not, all functions of the system you’ve coded, great and small, will mean something to somebody out there.

For the most part, when you build software that attracts users, you build dependency in ways you cannot predict. How your software is used is out of your hands. Someone may really count on behavior X, which you didn’t really anticipate being counted on, or want to be counted on, at all.

In a way, it’s endearing. When an unexpected dependency blooms, a developer discovers a new relationship between client and server. ​“Hey, I didn’t even mean to make our software do that particular thing,” they might say, ​“and yet now here we are.”

Despite the rigor of planning and testing, behaviors called chance and happenstance find ways to slip past the bouncer, and manage to make it, unnoticed, onto the software’s dance floor, requesting and responding. ​“I didn’t mean for you to fall in love with my product in that way!” shouts the company. But the heart wants what it wants. So the behaviors keep twerking.

What happens when you upgrade your software, and behavior X doesn’t get past the door anymore? Well, that’s when, I guess, people in the software industry experience a version of pain. They endure betrayal, rejection. That’s when Hyrum’s Law gets referred to. Users try to recapture the way things used to be. They try to hold on to the past.

Which is human. When you break someone’s reliance, even accidentally, there are feelings.

Feelings like panic at the tech standup meeting, where I came so close to disclosing my ignorance.

Which, to be fair, everyone is already well aware of.

^{*This is my best guess.
**I don’t know yet.}

Got some tech jargon you want me to misunderstand? Email me your jargon. I’ll botch it completely. (That’s a promise.)

‍