An example of bad coding is Amazon’s game, New World. They had lots of bugs, and when they tried to fix some bugs they broke other stuff that they weren’t even trying to change and didn’t know would change because it seemed unrelated.
Brief summary:
To get to this ideal state where almost none of one’s ideas have known flaws, it’s important to organize one’s ideas into small modular chunks with well-defined interfaces between them. This way, when an error occurs, it’s clear where the error is and what other ideas it affects, and it’s usually easier to fix the error. Just like in programming.
When you change APIs, the directly connected ideas are affected. In other words, other ideas/code that use that API have to change how they use it. The change is often pretty easy to make. For example, the old API might be dispense-drink(type), meaning you specify a drink type when calling the dispense-drink API. A change to the API could change the list of valid drink types or it could add a new variable to specify drink count. The API could be updated so instead of always dispensing one drink at a time, it could dispense multiple drinks of the same type when a number like 4 is specified. A more complicated API could allow dispensing multiple drinks of multiple different types with one API call.
Some changes to an API might not require changes to any callers. For example, if the API accepts a wider set of inputs as valid, then any code calling it with any inputs in the old range of valid values won’t have to change. For example, you might be able to change an API to make it dispense multiple drinks without breaking programs making calls the old way by saying that if no quantity is passed to it then it only dispenses one drink.
Yeah, sometimes backwards compatibility is maintained on purpose or incidentally when making changes.