In 1999, Brian Foote and Joseph Yoder wrote a paper called "Big Ball of Mud" in which they defined a pattern of the same name as follows:

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems."

Most of us have had much more first-hand experience with such systems than we'd like.

Why does this happen so often?

There must be some real forces that move software projects in this direction. What are these forces? Where are they coming from? What can we do about Big Balls of Mud? How can DDD help? These questions will be the topic of our discussion in March meeting.

----

You will need to RSVP by the end of business day of Tuesday, March 3rd: due to the building security requirements, we will need to provide them with a list of attendees. Please bring a photo ID.

If your are a new member and your profile does not have your first and last name, please RSVP with your full name, otherwise we will not be able to add you to the security list and the building security will not let you enter the building.

This meeting is sponsored by Bill Zack @ Microsoft who kindly provided the space and refreshments (thanks!!)