Re: Big Ball of Mud
This was written nearly 30 years ago! But all of the conclusions drawn in it are still valid! Software that exists around us continues to be a “Big Ball of Mud”. There might be some systems which are truly remarkable because of their simple design. They’ve resisted becoming a Big Ball of Mud over a long period of time. These systems are the exception that prove the rule.
Navigating these large systems of mostly unorganised code, using incomplete, outdated documentation, and (from 2026) AI tools, while simultaneously attempting to implement improvements and reduce maintenance burden, is the day-to-day work of software engineering.
As companies grow, complexity increases. However, revenue is always top of mind. High minded considerations of “architectural purity” seldom make the long journey from idea to reality.
A couple of quotes that resonated:
Indeed, an immature architecture can be an advantage in a growing system because data and functionality can migrate to their natural places in the system unencumbered by artificial architectural constraints. Premature architecture can be more dangerous than none at all, as unproved architectural hypotheses turn into straightjackets that discourage evolution and experimentation.
The software is ugly because the problem is ugly. Or at least, not well understood. Frequently, the organization of the system reflects the sprawl and history of the organization that built it.