in reply to Are design patterns worth it?

I don't think you have a problem-- or if you do, you also have the solution. You recognize the difference between "maintenance minefield" and "good, well-documented, loosely coupled, easy to maintain code." Once you've got that distinction, you can refactor the minefields into grassy plains as you need.

Design patterns do not define good design. They merely specify one way of getting there, and serve as examples of it. If the code is expandable, documented, and orthogonal, I don't care if it's DP-based or not.

My usual method of dealing with partially muddy designs is as follows:

The only worry about bad-but-working code is the fact that bad code begets bad code. If I'm working on a project that uses a lot of globals, it's always tempting to add more globals in my new code... after all, why not? There are globals there already. It's a quick downward slide to coding cynicism.

My interactions with a Big Ball of Mud are detailed in Failure To Refactor.