Submitted 8 hours ago by Icedrous@lemmy.ca to [deleted]
If someone were to write code to their software fixing bugs, how and why can that break other code/features if it’s not meant for that? A common example are Nvidia drivers “breaking” or Microsoft patching one feature but breaking many, many other features.
If code is meant to be hyper specific, how can it affect any other feature?
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
Your example is for graphics drivers, which are unbelievably complex, not to mention have to be designed to:
A) work in tandem with a crazy amount of different architectures, kernels, hardware setups and dependencies.
B) must reliably manage the demands of millions of complex calculations, monitor throughput and heat dissipation, handle complex and varying game configurations and technologies, all while simultaneously working as seamlessly as possible for us users.
The breaking could be from any one of the above systems and more having any number is issues or changes.
Simplified example: Function #185 requires specific feedback from system hardware output #768, but that output was updated by the another development team for another system driver to give the word “true” or “false” instead of a number indicating the same. Now, if that function is not designed to handle the change gracefully beforehand, then there is a problem. Hour severe the problem is depends on what subsystem of the driver software is affected.
Monitoring system? Maybe not a biggie, the graphing app gets killed or freezes. The actual driver gets the issue? Could be catastrophic failure, where the system freezes or restarts, or corrupts the driver install itself and you need to reinstall previous version. Worse case scenario, it really fails and fries hardware, but that’s rare. Failsafes usually kick in on the hardware side to mitigate that kind of damage.
Now times this by a probable factor of thousands of functions and hundreds of dependencies and you get the idea.
I’m not great at explaining things sometimes, so forgive me if the above doesn’t answer your question.
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.
🤷
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.
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 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.
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.
This happens a lot in the same application’s code, let alone between two different pieces of software.
You wouldn’t believe how often I go in to fix something in an app I’ve built and end up breaking something else despite never directly touching that. Like I have a music player I built and I’ll go in to fix an issue affecting skips at the beginning of the song and when I go to test, I find that issue is fixed but now the whole app’s color scheme has changed or some other unrelated issue has appeared.
Code is very finicky and fragile and relies on specific conditions it expects. The removal of a space somewhere in the code can do a lot of damage you never thought possible. You think it’s just an empty space, who cares? Nope! The code is expecting that space and when it doesn’t see it, it throws a fit and shit breaks.
And when we’re talking about issues on the same system, these applications talk to the same things or each other enough that they have a similar effect. One application expects specific conditions and when it doesn’t find those, it spazzes out. Nvidia’s software was given explicit instructions on where it needs to go and what it needs to do. But if another application does something that interferes with those instructions, your Nvidia GPU will start acting up. The application unrelated to Nvidia wasn’t written by someone who is aware of what Nvidia is doing and so an issue appears. And then these developers work to figure out what happened and provide an update to fix.
You can see why you’ll have more issues the more software you add into your system that’s unrelated to each other.
It’s like hiring a bunch of professionals to work around your home but not explicitly telling them about each other. You hire a landscaper, an exterminator, a maid, a butler, a chef, a chauffeur, a contractor… and all of them come to your house on the same day every week. Each of them has a job to do and on your end, their jobs seem independent enough that they won’t be bumping into each other, but you forget about the little stuff that will cause interference. The maid wants to clean the living room, but your exterminator is chasing down a mouse right now and is gassing the living room. The maid starts working in there to clean up but doesn’t know about the gas and now she gets knocked unconscious and this causes the rest of your house to remain in a disorderly state. This is also not even taking into account any issues that can happen from one person that affect the whole home and everyone else indirectly like if the contractor was fixing the foundation but he uses dynamite and the whole house comes crashing down and now no one else is able to do anything.
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 problem’s 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.
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.
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.
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.
breadsmasher@lemmy.world 8 hours ago
it isnt.
tunetardis@piefed.ca 5 hours ago
This.
As much as you try to keep various modules in your program functioning as independently from one another as possible so that you can unit test the shit out of them, the whole system is far more complex and interdependent in the end.
And that’s just within your own code. Bring in external libraries, drivers, etc. and it’s easy enough for fixes downstream to affect what happens further up.
One thing I find interesting is there seem to be cultural differences between platforms. In Windows, for example, it’s super common to see multiple versions of the same library installed, and apps dependent on a specific version, even if it’s rather ancient. Linux/Mac tends to frown on this? There may a stable version and development version, but that’s about it. So the onus is more on the app developers to make sure their code works with the latest library.
It’s also important to note that it’s not always an unanticipated effect. There may be some need to change a library to no longer support a certain usage. In that case, the old usage is marked “deprecated” and anyone using the library is given a window of time to make adjustments to the new interface, but if they don’t get there on time, the patch breaks their program. And in some cases, the adjustments can be major, requiring what amounts to a total rewrite.