if code is hyper specific

it isnt.

Nothing exists in a vacuum.

There is a break in a sewer line in town, so a crew goes out to fix it.

The crew’s only purpose is to fix sewer lines, but somehow, you’re still late for work.

Imagine you’re building a house, and you notice that a wall is not quite in the right spot, so you need to move it over a few inches. Sounds like a small change (just a few inches), but it’s easy to imagine that the construction might affect other parts of the house, or that you might see issues later because of the wall being moved over.

Not a perfect analogy, but a software change can sometimes seem small (just a few inches), but actually require a lot of complication

Software is generally built up in layers from reusable pieces. If there’s an assumption or a change in a lower layer or in one of those reusable pieces, things that might seem unrelated can break if they share one of those pieces

deleted by creator

The different parts of software are (maybe) meant to be independent, encapsulated from each other, but in practice it’s hard to actually do that. So if you change the behavior of one part, the other parts that depend on it directly or indirectly often need to be changed as well, and certain types of issues are easy to miss, especially when you aren’t targeting a homogenous hardware platform like a game console.

I’m system design there’s almost always a tension between efficiency and adaptability / robustness.

You can write software where code is very isolated and not shared and it makes it really easy to update it quickly and ship it and know that it will run properly, but the cost is usually that there’s more boundaries in the software that create little slowdowns and cause things to have to repeat and it adds up to a slower or more bloated program.

You also have instances where you write your software and it has a bug, and you later go to fix that bug, and you don’t realize that a whole bunch of other software relied on that bug being there.

For instance the Node.js team recently released a security patch that caused them to emit a proper .closing event. Unfortunately an old version of a very popular fetching library breaks when it receives that .closing event because is thought it was supposed to close. It’s fixable but it would be very hard for the node team to know that they would break another piece of software that was listening to undocumented events.

Good programmers try to follow the DRY principle: Don’t Repeat Yourself. A lot of times you need to do the same actions over and over in different parts of a program, so you write a function to do that, then just repeatedly call the function. If you have to modify a function to fix a bug in one place it might change the input/output somewhere else unexpected.

Imagine you’re writing a book. In this book you need to be perfectly consistent and coherent because the people reading it are so incredibly literal that if there’s ambiguity or inconsistency they will run into your home and defecate on your carpet.

Short stories are easy enough. There’s only a character or two and you can generally remember what they’re wearing and what they said, but as the stores get longer you start to work yourself into corners and lose track of what you said in the previous chapters.

Let’s say you reach a scene where the main character needs to hop on a train. You write a scene where they purchase a ticket. But wait, a few chapters ago you said they got mugged! So you decide to cut that scene. Now they can pay for a ticket, but the scene where they said they got mugged is wrong and the scene where they said they can’t pay their bill doesn’t work!

Computers read instructions and interpret them. They follow orders. Programming raw hardware is tricky, so we add abstractions to make it easier. Collectively we agree, “we’ll put a return pointer here, then push these instructions here and set the program counter here” as the way we call subroutines or send data or something else. If there’s ambiguity in the specification then two people might build two different programs which they both expect to work. One of them will fail. If there are ten people implementing things with an API, perhaps all ten will fail.

Hyrem’s Law says any observable behavior will eventually become part of a workflow.

I’ll give you a real world analogy. Have you ever tried to balance rocks? You can get two or three rocks balanced but that could put one of the lower balance points out of balance. It’s like that. That is the assumption that code has a singular dependence and it’s all linear is incorrect in most circumstances. Code often has many dependencies and many other parts depending on it.

It’s the tablecloth effect:

You sit at a beautiful and elegant table, with plates and glasses and food and all. You pull at the tablecloth on your side so maybe the glasses on your side fall over. But maybe also the glasses on the other side fall over.

They were connected somehow. Maybe you knew the connection, maybe not.

You want some examples?

Example 1:

lets say you have a variable named x

x is used in a lot of functions and classes, it’s a very important integer.

A function requires x to be a floating point number, though. Instead of creating a new variable, the developer makes x equal a float, which breaks all the functions expecting an int.

Example 2:

Developer uses a library A to build his own library B which in turn is relied upon by others. When Dev has to change this library A to a new library C due to deprecation or security vulnerability, they might not even notice any problems until later when it turns out the people using his library were already using a different library with the same name as library C, causing an industry standard software to fail to build for several days and millions of dollars lost.

Example 3:

Your code actually had all the bugs the entire time but it broke before it could even reach them, so you only saw one error until you fixed it.

If it was always happening the same way every time it wouldn’t happen…

There are many routes, but in your example, for instance, Microsoft updates don’t just have 1 fix for 1 issue but multiple fixes and new features, ideally Microsoft would have tests that cover all usages that they run before deployment, but they don’t (it’s a lot of code) but also it has to run on any combination of systems.

Then you throw vibe coding into the mix…

Another thing is if you had 2 similarly named variables and use the wrong one it might work one way but not another, someone is tasked to fix it and they see it using the wrong variable and correct it… great, but maybe other stuff was made since that now breaks because that variable is correct now.

And any issue relating to timing issues can just appear and disappear based on environmental conditions, a true nightmare to resolve well.

Exactly. Designs are tangled, causing unexpected explosions in the next building. And when I invite programmers to create less-tangled designs, they scoff and call it “overengineering”.

And then another explosion in the next building.

🤷

(This isn’t the only cause/effect path leading to unexpected defects, but it’s a very common one.)