Big Ball of Mud is an term that describes a system or computer program that has no real distinguishable architecture and is choking to death from all the mud that has been thrown on it to keep it alive.

Brian Foote and Joseph Yoder popularized the Big Ball of Mud term in their Big Ball of Mud paper.  That paper defines the term as:

"A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spagetti-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."

Big Ball of Mud systems are developed over a period of time, by different individuals with different skill levels doing what they think is best at the time.

Foote and Yoder do not universally condemn Big Ball of Mud programming. They point out that this pattern is most prevalent because it works — at least for the moment. However, as they become caked with mud programs of this pattern become maintenance nightmares producing less and less reliable results.

Overtime if left unchecked, the mud will eventually choke the system to death.

Often the best thing to do when you encounter a Big Ball of Mud system is to learn what it accomplishes and from that start drafting requirements for a new well architected system.

By the way, times when technology shifts (procedural to OO programming, client-server to web-based, file-based to database, the introduction of the internet etc.) can provide good reasons to kill off the Big Ball of Mud system and move on. Often Big Ball of Mud systems can not effectively take on the new technology which introduces the opportunity to kill the old system and build a new well architected system.

Which brings us back to the .NET Framework.  The .NET Framework is a technology shift - just ask any VB Classic programmer.

It you are responsible for a Big Ball of Mud system take another look at the .NET Framework. 

It may be the road to your salvation.