Big Ball of Mud (1999)
laputan.org
laputan.org
The organization and/or the developers responsible for the day-to-day development and maintenance of the application do not care enough to go back and refactor code once it has become apparent that there is excessive duplication of code and that the duplication/intimacy with the code has revealed the patterns that are necessary for the refactoring to be successful. I'm not sure if there's any sure-fire solution to this issue, other than (possibly) increased pay/benefits or some other form of reward. After all, developers that care in the first place don't normally require extra rewards for caring because they view the end result as the reward (clean code that is reliable, performant, and satisfies the end user/customer). So, at most, you might gain some extra, superficial "caring", but how long-lasting that will be is anyone's guess.
One additional thing I'll add: Over the years it's become clear to me that the big ball of mud is not necessarily the worst end state. It means the code was valuable enough to maintain, and important enough to continue to extend.
"Change: The fundamental problem with top-down design is that real world requirement are inevitably moving targets. You can't simply aspire to solve the problem at hand once and for all, because, by the time you're done, the problem will have changed out from underneath you. You can't simply do what the customer wants, for quite often, they don't know what they want. You can't simply plan, you have to plan to be able to adapt. If you can't fully anticipate what is going to happen, you must be prepared to be nimble."
"Therefore, incrementally address forces that encourage change and growth. Allow opportunities for growth to be exploited locally, as they occur. Refactor unrelentingly."