‘Big ball of mud’ is a humorous term given to describe systems with no discernable architecture. ^[1] These are systems where code has been developed in a rush and with little care.

In a ‘big ball of mud’, there is no structure or guiding principle. Changes are made to minimize the short-term time or effort, while letting long term problems accumulate.

The consequence of a ‘big ball of mud’ is code that has many poor design decisions:

Professional developers will sometimes make a strategic decision to prioritize short-term concerns due to an impending deadline. This is sometimes referred to as accumulating technical debt. However, developers should make such decisions with a plan to pay down that debt and avoid a ‘big ball of mud’ by refactoring or improving the code as soon as the deadline has passed. ^[2]

Unfortunately, this architecture is pervasive. It is common because short-term thinking is common. Short-term thinking is common because business is highly competitive. It is easier for a business to see the benefit of rushing new features for customers than improving the architecture.

As professional developers, we all need to learn to communicate the business benefits of good architecture. It is not persuasive to claim that architecture is a priority because ‘it makes the programmers happy’. A more sophisticated argument depends on professional developers understanding the organization’s desired quality characteristics (Chapter 10). Most organizations care about more than functional suitability. Good architecture is essential to achieving quality that benefits customers and grows the profitability of an organization.