There's a very short chapter in one of the books I like, Working Effectively With Legacy Code, entitled "We Feel Overwhelmed. It Isn't Going To Get Any Better."

There's a very short chapter in one of the books I like, Working Effectively With Legacy Code, entitled "We Feel Overwhelmed. It Isn't Going To Get Any Better." The chapter offers little more than hope based on seeing turnarounds happen -- once you get some control over your code, you start developing little oases that are pleasant to work in, even if the rest is crap. I see something similar with large software systems. A 'system' is something that can stand alone, but very large software is logically composed of many subsystems that could in theory stand alone even if presently they never stand apart from the full system or if their components are so intertwined that the logical subsystem is only a potential abstraction. While the full system might be a ball of mud, and you have little to no control over what Team X does with their subsystems and their relations/interconnects with the overall system, it is possible to rework your own subsystems in a way that they themselves aren't balls of mud and stay that way indefinitely. (I suspect this is part of some of the optimism behind microservices -- followed by pessimism when people realize the full system that interconnects everything can still easily become (or start as) a ball of mud, one even less pleasant to work in than in a monolith design.)