Hyrum's Law:
"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."
I once worked at a place where we essentially were unable to fix bugs because it was a no-code tool so people would do all kinds of wacky things with the system.
The mandate was, as far as I can tell, to enshrine these former bugs into actual documented features. I wish I had seen this as a warning for how the place was ran but I also needed the money.
That was on top of people doing completely stupid things and abusing the systems we gave them in exchange for way too little money. It got to the point where the company was offering dedicated servers as an upsell because there were clients that were paying far too little money, in my opinion, for the amount of resources they were taking up.
The breaking point came when I got woken up at 3am two nights in a row by a client who was very obviously an Indian scam call center who was paying us something like $100 / mo to have a button that calls an engineer at any time. The problem was they had something like 7 layers of recursion through their app and each update was causing cascading updates and unsurprisingly was taxing the entire server causing updates to be slow and/or unreliable.
Maybe I just sucked at it but I told leadership we need to jack up prices on that button and kick these pretty obvious scammers off the platform. I left a few months later.
I was going to make a tongue-in-cheek suggestion about randomizing undefined behaviour, but I suppose that's common in debugging and even seen in some APIs.
At one time, in Python, dictionary (hashmap) ordering was randomized so users wouldn't rely on non-specified ordering behaviour. Eventually though, dictionaries were guaranteed insertion ordering.
The opposite problem is much more common and shouldn't be downplayed: A developer or designer using the "every change breaks someone's workflow" exaggeration as an excuse to break a workflow.
The fact that any change to software people are used to using will bring pain to the users shouldn't mean that devs automatically prefer or avoid breaking workflows. What it should do is encourage actually thinking about the cost/benefit (to the user) of the change.
Users will accept the pain that change brings if the benefits of that change outweigh the cost of it. If the cost/benefit ratio isn't favorable to the user, they will, quite understandably, resent the change.
I was just thinking about that today as I was reading through some bug reports of the podcast app I'm using (Overcast). Someone was happy that a bug got fixed that caused an issue for them, they shared a screen recording and you can see that they use what looked like 300 playlists with filters to sort their podcasts into all kinds of buckets.
The developer of the software commented: "This is the most playlists I’ve ever seen. By far."
We’ve discovered with experience that every app which looks like a table and allows free text fields will be repurposed as a job applicant tracking tool, with uncontrolled discrimination comments.
And this is bad because it’s not GDPR-compliant (but fortunately, it’s not the fault of the software vendor, but of the data controller).
This is why it is important to stratify your API promises.
Git is a good example of this, with "plumbing" commands meant for scripts and software and "porcelain" commands meant for a more comfortable user experience. Code is rigid while humans are flexible.
Only freeze APIs that have been proven in the field to be stable and necessary in the field by thousands of people.
Well to be fair, most people don't look at the apt's output in their scripts, they just do "apt install -y --no-install-recommends all the wonderful packages they need" and move on with "&&".
If that was the case then I wouldn't see messages that X or Y commands behavior are going to change in the future. The master branch moral panic thing comes to mind for example.
This is why I don't like semantic versioning. Semantic versioning only covers the "public API" but even the smallest "patch" change can result in a change in behaviour which has a big impact on the users.
On the other hand, I've seen some Go libraries explicitly dropping support for old Go versions in their "patch"-level releases. So some developers clearly consider being now unable to compile the library a backwards-compatible change.
This is covered in the spec. "Use your best judgement" is the answer. What's the other solution? Just give up and version you software sequentially/by timestamp?
Not serde, but newer version of rust, no?
Nope, checking GitHub, I can’t see any issues about either of those two things combined with blobs.
Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? I love NixOS, but the hacks they do to injevt determinism are obviously built on implementation details that most upstream projects need to keep opaque to continue improving. I’d much rather see upstream collaborate instead of have nix pees dictate that all current observed behaviour of any piece of software must be set in stone from the first reference in nixpkgs.
Issue was: new type inference caused problems for old version of the time crate. Newer versions worked with 1.80, but many crates weren't updated to the latest.
> Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks?
According to Semver - no. According to people affected - yes.
I often state this, but:
Backwards compatibility ⇒ Semver (read: Backwards compatibility implies SemVer, but not the other way around).
Who's right? Is it fine to speed up compilation but disrupt people using serde on Arch? It depends. According to strict Backwards compatibility guarantee - no. However according to them, you need to backport bugs and exploits.
https://www.hyrumslaw.com/