I've always been partial to the concept of ravioli code which I read about from John Papa. Contained modules that do a job that can be added or removed. You decide whether or not you need that modules fucntionality with no other module having a dependancy on other modules.

I agree with the spirit of this article, having a responsive code base with easily replaceable code. But this becomes a problem when you have a code base with sprawling legacy modules with essential functions for core customers that new code must interface with.

I worked for a company that attempted to incorporate agile methodology to add features on to a large legacy system to try and stay responsive to customer feedback. The problen was when new features were added we were only adding on to the "cruft" mentioned in the article. As unintentional as it was new code would start to tightly couple with legacy code. In spite of that we kept continuously adding new features with the predictable results of more tech debt, bugs and on-call catastrophes.

I'm all for responsive code that instantly reflects customer requirements but it requires a lot of discipline and planning.

Ideally, "legacy code" wouldnt exist at all and keeping a low half life should help with that. But in the real world, with people being the irrational, nepotic, lazy and self-deluding creatures we are, thats not going to happen. I'd caution anyone to really know what theyre doing before rationalizing poor design choices by thinking "it's not technical debt if were going to throw the code away anyway!"

I'm sure that's what the original authors were thinking when they wrote that awful legacy monstrosity you're dealing with now.