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.

deleted by creator

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.

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.

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.)

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.