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:

• If the code works and doesn't need to change, I don't mess with it. I write automated unit tests for it as a background task, just in case I ever do need to fix it.
• If I need to make a change, I start by checking my unit tests to make sure they test things out well. Then I refactor bit by bit.
• If the code doesn't work, then I'll rewrite it-- or at least the broken portions.

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.

stephen