Here I'll describe an issue that comes up when we write our code. As we add more functionality, we sometimes decide to delete old one, but do so only partially. Or we write incomplete code. Or we comment it to be there just in case something goes wrong. This is how code becomes obsolete and carefully thought-out architectures start to decay.
When we create the structure (HTML) for a website, we often use ids and classes as attributes and apply styles (CSS) to them. The problem is that once we change the name of an id or class, its corresponding style is no more valid, so we have to go again there and rename all selectors that used the old name. This might look as trivial, but it isn't. Especially when we start to see the other associations, that are really aggregations, because they remain once the part they relate to gets deleted. The more technologies we use, the more "glue" we need to bind them.
We can also specify a "name" attribute to an input element to store the user's data on the server in combination with a POST request. But if we change that attribute, again, the server-side code relying on this variable will cease to work.
We can fill a database table with some data, but only as long as we know the names of the columns we wish to affect. If we change the database schema, the server-side code will also need to be changed. Chances to forget to change the changes aren't quite small.
This shows that work is done twice for every unique, interconnected technology couple. If there are many different people with fragmented responsibilities on a team, they may need common standards or an extensive and costly communication to prevent that things get out of control. At the end, the internal connections between people might start to resemble the technological ones in their nature.
This should be a reminder for us to change our associations as we change our code to minimize the quality decrease in our system.