a legacy codebase can be structurally resistant to being fixed.
you're afraid to change things because there's no test coverage. okay let's add some automated tests. oops can't do that either because the whole thing is a tightly-coupled pile of spaghetti with no interface boundaries. so you start by refactoring. but because there are no tests, you don't realize you are breaking a bunch of important business functionality and now people are yelling at you to stop whatever you are doing and fix these bugs.
no matter what you do, it's going to get a lot worse before it gets better. but hey, people are actually getting stuff done with your product/service in the meantime. as painful as it is, it's still probably better to fix what you have than to start over.
This captures the backwards compatibility and long range entangled dependencies aspect of change resistance. It misses the aspect of organizations that is agent like, capable of homeostasis. Unlike static code, when things change, such systems will actively seek policies and apply levers of control to maintain the present equilibrium.
Like biological agents, I'd argue any persistent and stable organization of humans makes predictions and inferences about the future and takes actions which maximize the probability of their future existence as a coherent entity.
in a vacuum yes, the legacy system doesn't have any of those agent-driven issues. given enough time and freedom from interference, you can incrementally fix it or rewrite the whole thing from scratch. but if you leave out the context of users and management, it doesn't really matter how you choose to fix it or whether you do at all.
in reality, you have customers that are very upset about the sudden spike in observable defects, you have other teams mad because they are triaging a bunch of bugs introduced by your refactor, and you have management wondering why the fuck you have spent multiple months working on stuff that has no clear connection to a marketable feature. you might also have a couple of seniors/principals who actively oppose your efforts because they benefit from being the only people who really understand the mess you are trying to clean up. and of course, all of that messy people stuff is probably a large part of why the system is so tangled up to begin with.
I certainly don't think political systems are exactly like computer systems, but it seems like a lot of the high-level lessons are applicable to both.
> in reality, you have customers that are very upset about the sudden spike in observable defects...a bunch of bugs introduced by your refactor
That's what I meant to capture by agreeing there is overlap in terms of backwards compatibility and entangled dependencies.
The difference is entrenched social systems have greater agency that goes beyond change induced instability and into being able to actively predict and favorably mold their environment.
you're afraid to change things because there's no test coverage. okay let's add some automated tests. oops can't do that either because the whole thing is a tightly-coupled pile of spaghetti with no interface boundaries. so you start by refactoring. but because there are no tests, you don't realize you are breaking a bunch of important business functionality and now people are yelling at you to stop whatever you are doing and fix these bugs.
no matter what you do, it's going to get a lot worse before it gets better. but hey, people are actually getting stuff done with your product/service in the meantime. as painful as it is, it's still probably better to fix what you have than to start over.