Big Ball of Mud (1999)

http://www.laputan.org/mud/

by WillyOnWheels • 9 years ago

73 6 9 years ago

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• 9 years ago

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

eric_b• 9 years ago

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.

willtim• 9 years ago

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

TimJYoung• 9 years ago

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.

aryehof• 9 years ago

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?

Big Ball of Mud (1999)

Related Stories