
Big Ball of Mud (1999) - WillyOnWheels
http://www.laputan.org/mud/
======
TimJYoung
It's very simple ("Beware of simple solutions to complex problems" :-) ):

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.

------
eric_b
This is a classic. After more than a decade in the bowels of the Fortune 500,
this rings as true today as ever. I try and re-read every couple of years to
refresh my memory.

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.

------
killjoywashere
This seems to presuppose you are starting with a vast group of highly skilled
subspecialists who, in aggregate, understand everything about the system, from
the chip design, OS, routing, database, etc. In reality, you usually start
with just enough understanding to sketch a first draft of what you think the
problem might be.

~~~
dandelany
...Are we reading the same document? The entire point of this article is
_acknowledging_ these real-world issues and figuring out how to effectively
deal with them. For example, from the "Piecemeal Growth" section:

"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."

------
willtim
It's been a few years since I last read this. Beautifully written, with great
metaphors.

------
aryehof
A classic. I fear however, we have made no progress towards preventing mud
balls since this was written. There are two old methods of application design
predominantly used today:- functional decomposition and information (data)
modeling. Both lead to big balls of mud as size and complexity of a problem
domain increase. Have we given up on finding ways to model a problem or system
into code in a better way?

