An interesting meta-pattern appeared in my thoughts when I combined GPD, DFD, WAD, IAD, CYAE, and DBD. It's acronym is FDD, which stands for Fear Driven Development.
A few other patterns may make appearances, depending on the organization, but the practical upshot is something a former manager of mine kept on about regarding working at large, asshole driven organizations: focus only on requirements. Do precisely what you are told to do, and precisely what you are told to do it on, and do absolutely nothing else to anything else. For developers, this involves fixing or implementing precisely what the bug ticket tells you to, and committing precisely that to the repository. For the tester, this involves testing precisely that feature or fix the ticket indicates, and not suggesting in any way that another related fix could be rolled into this one with little effort. For the project manager, this consists of having endless meetings with people to make absolutely certain the items on the task list are prioritized correctly, and dragging developers and testers into those meetings to project an image that your organization is "engineering driven".
Expect that if you violate this tenet, you will face unwanted consequences, even if things turn out well for what you were working on. It doesn't matter that you made things better for the organzation; you usurped the task-delegation authority of someone else, and it is quite possible that person was hired for that specific purpose. If you show you can self-manage, this person is now redundant, so it is in their best interest to show you can't self-manage by making sure you are scared completely shitless of ever doing so. Vague threats and social politics work well here.
But it's not that the individual wants to abide by these particular patterns; it's that they are wedged into a political canyon. They know that whatever effort they might put in to making things better will result in them being fired for insubordination as soon as someone finds out what they've done. Would they like to keep their job and deal with a horrible codebase, or would they like to lose their job and have nothing but the bitter taste of a horrible legacy codebase you can now do nothing about.
These are all symptoms; the cause I've always seen is that the staff are scared shitless, and want to make sure no one can hold them responsible for anything. It seems to me that if you get rid of that, you get rid of the catalyst behind a lot of these other problems.