Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptArchitectural conditionChapter III · Evolution · Building block 15 of 15

Big Ball of Mud

Local additions can gradually dissolve effective module boundaries.

By Michael Meierhoff · Meierhoff Systems

  1. CouplingCoupling: Changes cross module boundaries unpredictably.
  2. AccretionAccretion: New requirements accumulate without a coherent design.
  3. ReconstructionReconstruction: Incremental boundaries make evolution manageable again.

Context

Why this is important

Recognize structural entropy through actual change impact.

Recognize structural entropy through actual change impact.

Shop example · Mapping

Big Ball of Mud: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. In the shop, pricing rules are copied in several places, and a change to order status requires edits across catalogue, cart, invoice, and shipping code. Software analytics shows files that change together often; an architecture review confirms that business boundaries barely hold in code. The team first stabilizes critical flows, assigns pricing to a clear module, and adds a contract test. Subsequent changes cut coupling incrementally while the shop continues to ship.

This is how you read the picture

  1. Coupling Coupling
  2. Accretion Accretion
  3. Reconstruction Reconstruction
Big Ball of Mud: inspect the decision
ConceptMeaningReview question
CouplingChanges cross module boundaries unpredictably.Which files often change together in the shop?
AccretionNew requirements accumulate without a coherent design.Which evidence supports a module boundary?
ReconstructionIncremental boundaries make evolution manageable again.Why is co-change alone not a refactoring prescription?
Foote und Yoder zeigen auch Kräfte, die das Muster entstehen lassen: schnelle Lieferung, fehlende Erfahrung und dauerhaft weiterverwendete Prototypen. Erkennen heißt daher zuerst, reale Abhängigkeiten und Änderungsfolgen sichtbar zu machen; eine pauschale Neuschreibung folgt daraus nicht. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Recognize structural entropy through actual change impact.
  • Evidence change coupling through concrete code and release paths.

Boundaries

  • The label summarizes symptoms but does not determine a modernization strategy by itself.
  • Co-changes can also reflect legitimate business collaboration and need code and team context.

In practice

  1. Choose a concrete pricing-rule change and trace through code, releases, and tests which of the seven shop modules independently alter the same rule.
  2. Validate observed change coupling in an architecture review and distinguish domain dependency from shared code or mere repository proximity.
  3. Move one pricing rule into a clearly responsible module, add a contract test, and compare affected locations and released defects at the next change.
Read the detailed explanation

Big Ball of Mud describes a system with loose or conflicting structure whose organization has grown mainly through short-term additions and local constraints. It names an architectural condition, not a particular language or team decision.

Foote and Yoder also describe forces that produce the pattern: rapid delivery, limited experience, and prototypes that remain in use. Recognition therefore begins by exposing real dependencies and change impact; it does not prescribe a wholesale rewrite.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. In the shop, pricing rules are copied in several places, and a change to order status requires edits across catalogue, cart, invoice, and shipping code. Software analytics shows files that change together often; an architecture review confirms that business boundaries barely hold in code. The team first stabilizes critical flows, assigns pricing to a clear module, and adds a contract test. Subsequent changes cut coupling incrementally while the shop continues to ship. software analytics and einfachheit help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which files often change together in the shop?

    View the solution with justification

    Pricing rules and order-status code across several modules.

  2. ApplyingTransferred to a new situation

    Which evidence supports a module boundary?

    View the solution with justification

    Examine ownership, dependencies, and release paths for pricing rules together.

  3. EvaluateWeighing an alternative

    Why is co-change alone not a refactoring prescription?

    View the solution with justification

    Co-changes can be business-valid and need domain context.

Explore further

These building blocks continue the thoughts of this page.

PrinciplesSimplicity & complexity budgetContext and comparisonOpening EvolutionSoftware AnalyticsConceptual connectionOpening

References

Continue on the learning path

With that, you have Evolution & assessment run through. It continues with Documentation & communication.

15 Building blocks

Next areaDocumentation & communication