Change it, like it or leave it

After twelve articles, you might expect the Big Ball of Mud to eventually reduce to a simple cause.

Perhaps poor architecture. Too little refactoring. A lack of technical leadership. Time pressure. Legacy. Management decisions. Developers who accumulated too many exceptions over the years.

And once the cause has been identified, surely a clear solution should follow.

That is not what happened in this series.

The longer we looked at the Big Ball of Mud, the more apparent contradictions became visible. Systems can be technically problematic and operationally stable. Experts can solve enormous problems while simultaneously reinforcing structural dependencies. Organizations can suffer from poor architecture and still make a perfectly rational decision not to change it fundamentally. People can experience the same working environment as an interesting challenge, an acceptable reality, or a conflict they can barely tolerate any longer.

These things only look contradictory as long as we try to explain the Big Ball of Mud exclusively as a code problem.

The Big Ball of Mud is full of contradictions that only appear contradictory when we look at it exclusively as a code problem.

The definition of the Big Ball of Mud already drew an important boundary: a Big Ball of Mud is not simply a monolith, nor is it simply an old or large system. What matters is a structural condition in which the visible or intended architecture becomes an increasingly unreliable explanation of how the system is actually organized.

At the end of this series, it is worth widening that perspective one more time.

A long-lived Big Ball of Mud eventually consists of more than code and dependencies. Processes, knowledge, roles, economic decisions, and human adaptation strategies form around it. These layers react to one another. They compensate for weaknesses, create new dependencies, and can stabilize a condition that, from a purely technical perspective, ought to look remarkably unstable.

It works — and can still be structurally eroded

One of the most important distinctions in this series was also one of the simplest.

A Big Ball of Mud does not have to stop working.

The product can generate revenue, serve customers, satisfy regulatory requirements, and operate reliably. Releases can happen. New features can ship. Incidents can remain manageable. The software can deliver substantial business value for many years.

That is why the reaction ”But It Works” is not naive. From a stakeholder’s perspective, it is initially entirely legitimate.

The structural condition, however, answers a different question from the current state of the product.

A software system can deliver reliable value today while becoming steadily worse at being changed tomorrow.

Functionality and changeability are different quality dimensions.

A system is therefore not simply “broken” because its architecture has deteriorated. It may continue to fulfill its current purpose well. The structure becomes problematic where today’s success hides the effort and uncertainty that future change has started to require.

That is precisely what can make a Big Ball of Mud so long-lived. The immediate proof that something must fundamentally change is often missing. What is visible still works. What deteriorates is the ability to respond to a future that has not happened yet.

Nobody built it — and yet many people contributed to it

Likewise, a Big Ball of Mud rarely begins with a decision to build bad architecture.

The article Nobody Built It therefore did not look for a culprit. A long-lived system accumulates local decisions over the years: proofs of concept become products, exceptions remain, consolidation is postponed, requirements change, teams turn over, responsibilities are reorganized, and time pressure produces solutions that make sense in the moment.

No single decision has to explain the later state.

Only their history does.

Architecture emerges not only from what we deliberately design. It also emerges from what we fail to take back over the years.

That creates another paradox: nobody has to have planned the Big Ball of Mud even though many people may have contributed to its emergence.

This does not dissolve responsibility. Developers make technical decisions. Architects establish boundaries or fail to establish them. Leadership creates constraints. Product ownership sets priorities. Organizations distribute budgets and responsibilities.

But blame explains very little about why particular decisions were able to reinforce one another over many years.

Avoiding blame does not mean dissolving responsibility. It simply means refusing to reduce a systemic problem to individual people.

It has structure — but that structure no longer explains it reliably

Even the word mud can be misleading.

A Big Ball of Mud is not necessarily a completely shapeless codebase. It may still contain modules, layers, folders, services, components, and detailed architecture diagrams. The system may even look remarkably tidy if all you inspect is the directory tree.

What matters is whether that structure still holds.

The article on recognizing a Big Ball of Mud in the frontend therefore did not focus on a single oversized component or a poorly designed service. The condition becomes critical when the intended boundaries themselves lose their effect.

A domain slice may exist while other slices directly access its internal services. A domain layer may exist while business rules are simultaneously reproduced in components, effects, mappers, and HTTP services. A public API may be defined while being bypassed whenever convenient.

A boundary that everyone can cross at will eventually becomes nothing more than a folder name.

A Big Ball of Mud therefore does not necessarily lose all structure. It loses the reliability of that structure as an explanation of the system.

That is what makes architecture less useful. Its job is not merely to arrange files neatly. It is supposed to constrain the space of possible dependencies. It should help us predict where a responsibility belongs, which parts are allowed to know about one another, and which context is relevant for a change.

When that predictive power disappears, architecture can remain visible while no longer providing enough orientation.

Changes are described as small — and become large inside the system

A user story can be three sentences long. The actual patch may contain only a few lines. The business behavior may be entirely straightforward.

And yet making the change safely can require understanding a large part of the system.

In When Every Change Hurts Everywhere, we distinguished three different radii: the business radius, the technical change radius, and the understanding and regression radius.

In a well-bounded system, these radii are often relatively close to one another. A local business change has a sufficiently local technical impact area.

In a Big Ball of Mud, they can drift apart.

In a Big Ball of Mud, change loses its locality.

The problem is not necessarily that the diff itself is particularly large.

The size of the diff is not the problem. The uncertainty about its effects is.

That also changes the economic meaning of a change. The visible code is only part of the work. Understanding, coordination, regression, and assurance can consume a much larger share.

A small requirement is still a small requirement.

The system makes it large.

The expert saves the system — and thereby keeps it operable

Where explicit structure provides less guidance, implicit knowledge becomes more valuable.

Long-lived systems therefore often produce people who understand relationships that would require substantial effort to reconstruct from the codebase alone. They know historical decisions, hidden edge cases, dangerous areas, release rituals, and dependencies that appear in no architecture diagram.

Those people are valuable.

The Architect the System Cannot Live Without was therefore explicitly not a criticism of expertise. Difficult systems need experienced people, and exceptional technical competence is not an architecture problem.

The problem is concentration.

The expert becomes indispensable because the system is bad. And the system can remain bad because the expert is indispensable.

When the same people repeatedly receive the difficult work, they learn even more about the critical areas. The organization trusts them more. The next time something goes wrong, they are brought in earlier. Other developers get fewer opportunities to build the same knowledge.

A dependency can therefore stabilize itself even though nobody deliberately created it.

A key individual can be one of the most valuable people in the system and one of its greatest risks at the same time.

The correct conclusion is not to devalue expertise or remove the expert from the system.

The problem is not the expert.

The problem is the monopoly.

More safeguards help — and can hide structural problems at the same time

A system that is difficult to change does not have to fail constantly.

Organizations can become remarkably good at compensating for its risks.

They add regression tests. They establish additional reviews. They require experienced people to approve critical changes. Releases acquire special procedures. Test phases become longer. Certain areas are touched only by certain developers. Workarounds are documented. Incident procedures emerge for known failure patterns.

None of these measures is automatically bad.

Many are necessary under the circumstances. Additional tests can prevent real defects. Reviews can distribute knowledge. A cautious release process can be entirely appropriate for a business-critical system.

The interesting effect appears only at the system level.

The more successfully an organization absorbs the consequences of structural uncertainty, the less directly that uncertainty has to appear as a technical problem.

A Big Ball of Mud can be technically chaotic and operationally remarkably stable.

This was already one of the central observations in the first article of the series.

The system does not simply work despite the additional compensation. Part of its stability may arise precisely because people and processes absorb the lack of structural predictability.

That is a real achievement, but it also shifts costs into processes, knowledge, coordination, and additional assurance.

Developers appear slower — even though just as much work is being done

From outside the development organization, that shift is not always easy to see.

A team can work with the same focus and commitment as before while delivering less new business functionality. An increasing share of its capacity may now be required simply to make safe changes possible: understanding existing behavior, reconstructing effects, checking edge cases, coordinating with other teams, preventing regressions, fixing follow-up defects, or involving key experts.

Output does not necessarily fall because less work is being done. A growing share of the work may be required merely to compensate for the changeability of the existing system.

That can create a dangerous shift in perspective.

What the development team experiences as growing understanding and assurance work may look from outside like a performance problem.

The business requirement has not become larger.

So why does it take longer?

If the structural cost is invisible, a personnel explanation is tempting: perhaps developers have become slower, the team is too large, estimates are poor, or too much time is being spent on “technical” work.

Sometimes any of those explanations may be true.

But in a Big Ball of Mud there is another possibility:

The team is not doing less work. The system now demands more work for the same change.

The system can be economically rational — and still represent a risk

None of this automatically implies that the economically correct response is to transform the system fundamentally.

The article on the economics of a Big Ball of Mud deliberately began with the counterposition: a technically eroded system can be entirely rational from a business perspective.

A product at the end of its lifecycle may require only a handful of changes. The maintenance team is small. Replacement has already been decided. No new integrations are planned. A broad reconstruction would consume substantial investment and introduce transition risk without paying back during the remaining lifetime of the product.

In that situation, continuing to work with the existing structure may be the sensible decision.

Architecture does not possess economic value merely because it becomes cleaner.

The other side of that decision still remains:

“We do not plan any more changes” is not the same as “we will not have to make any more changes.”

Security requirements, regulation, operating systems, browsers, cloud platforms, external APIs, and other dependencies have lifecycles of their own. Not every future change appears on today’s roadmap.

That is why the economic meaning of a Big Ball of Mud does not depend solely on its technical condition.

The economic significance of a Big Ball of Mud depends on what the organization will still require from that system in the future.

The same technical system may be tolerable for a product that is being phased out and a significant risk for a strategic core product.

There is no contradiction in that either.

They are different economic situations.

People adapt to the system — and help stabilize it

For developers, software is not only a technical artifact.

When people spend years working on the same system, its structure becomes part of their working environment.

The article about what a Big Ball of Mud does to people therefore deliberately asked more than questions about code quality. People learn which areas are risky. They know the safe paths. They know whom they need to ask. They accept certain workarounds, build mental models of implicit relationships, or reduce their expectations about which changes are still realistic.

Others experience a stronger conflict with this way of working. They see clear structural problems, feel responsibility for improving them, and at the same time discover that their actual decision-making power is insufficient.

None of these reactions should be treated as a simple personality type.

People change. They may begin by trying to improve structure and become more pragmatic later. They may start as navigators and eventually initiate change. The same environment can feel entirely different to the same person at different points in time.

What matters for the system perspective is something else:

A Big Ball of Mud can be technically chaotic and socially remarkably stable.

At some point, it is no longer only the software that adapts to changing requirements and organizations.

People begin to adapt to the software.

That adaptation, too, can help keep the system working.

It can be changed — but not alone

None of these mechanisms means that a Big Ball of Mud cannot be changed.

Local refactoring remains useful. Michael Feathers’ work on legacy code remains useful. Strangler-style reconstruction can gradually restore boundaries. Requirements engineering can help separate historical implementation behavior from what the business actually still needs. Acceptance and end-to-end tests can provide an external safety net during reconstruction.

The previous article on ways out of a Big Ball of Mud examined these approaches in more detail.

Its most important statement, however, was not a technical technique.

A Big Ball of Mud should never be rescued by one person alone.

That is not an empirical law. It is an architectural stance.

A systemic condition eventually includes technical structures, business behavior, knowledge, decision rights, operational processes, and organizational constraints at the same time. One developer can still achieve a great deal. They can identify a boundary, demonstrate a better solution, introduce tests, or create the first viable reconstruction step.

But they cannot manufacture all of the required conditions alone.

If the solution once again depends on one person understanding the entire system, making every important decision, and personally ensuring that everyone uses the new structure correctly, then the technical problem may have improved while the organizational problem has been reproduced.

The way out of a Big Ball of Mud is not a hero story. It is a collectively supported reconstruction.

Many properties of a Big Ball of Mud appear contradictory as long as we treat it only as a technical problem. Its stability becomes understandable only when technical, organizational, economic, and human perspectives are considered together.

A stabilized socio-technical equilibrium

Perhaps the entire series can be condensed into one observation:

A Big Ball of Mud is not a state in which nothing works. It is a state in which more and more things have to work so that the system can continue to be changed.

The technical structure becomes harder to understand. People and organizations respond with additional knowledge, tests, processes, coordination, and assurance.

Those mechanisms make further change possible.

The product can therefore continue to deliver value.

The immediate pressure to change the technical structure fundamentally may decrease.

And precisely because the compensation works, those compensating mechanisms can themselves become part of the system’s stability.

As a synthesis, a long-lived Big Ball of Mud can therefore cautiously be viewed as a stabilized socio-technical equilibrium.

This is not a formal theory of the Big Ball of Mud. It is a perspective on the mechanisms examined throughout this series.

Technical structure influences ways of working. Ways of working compensate for technical structure. Organizations adapt their processes. Experts accumulate knowledge. That knowledge keeps the system operable. Successful compensation can reduce the immediate pressure to act.

The Big Ball of Mud does not survive only because nobody changes it. It can also survive because a remarkable number of people have learned how to compensate for its consequences.

The costs do not disappear; they can shift into people, processes, knowledge, coordination, time, and risk.

How much those costs grow and whether they become economically significant depends on the specific system. It would be just as misleading to derive an inevitably exponential cost curve from this as it would be to claim that every Big Ball of Mud must eventually fail completely.

Many never reach that point because they are replaced first. Others are reconstructed incrementally; still others continue running for many years.

This is not a morality tale

This series is therefore not a story of good architects versus bad management.

It is not a story of disciplined developers versus people who supposedly write bad software.

It is not a story of modern frameworks versus legacy, nor one in which refactoring is morally superior to feature development.

A Big Ball of Mud emerges and persists through more complex interactions.

That does not mean every decision is equally good. It does not mean nobody makes mistakes. And it does not mean individual interests, power, or poor technical decisions should disappear from the analysis.

Responsibility still exists; blame simply explains the phenomenon badly.

Especially in long-lived systems, the more useful question is rarely:

Who caused this?

It is:

Which technical and organizational conditions keep reproducing this state?

And only then:

Which of those conditions can and should be changed?

So far, those have been questions about the system.

At the end of this series, one more perspective remains.

The perspective of the individual person working inside that system.

From the system question to the personal question

An experienced developer or architect can recognize a Big Ball of Mud.

They can explain why boundaries no longer hold. They can visualize dependencies, examine change radii, identify knowledge monopolies, and describe economic consequences. They may even know a technically realistic path toward a better structure.

None of that creates an automatic personal obligation.

You are not obligated to rescue every Big Ball of Mud simply because you recognized it.

People with significant technical responsibility can easily make a different equation:

I see the problem. Therefore I have to solve it.

The entire series argues against that simplification.

Meaningful change requires more than technical competence, depending on its scope. It needs allies, business decision-making authority, organizational room to act, time, economic viability, and at least enough willingness from the organization to allow the resulting changes to take hold.

One person can advocate for these conditions, influence them, and create some of them. They cannot control them completely.

That changes the personal question.

Two questions instead of one

It is not enough to ask:

Can this system be changed?

A second question matters at least as much:

Can I contribute meaningfully to that change under the conditions that actually exist — and do I want to?

The first part concerns real room for action.

Are structural improvements actually accepted? Are there allies? Can business decisions be made? Is there at least limited time and organizational legitimacy? Do technical decisions have a realistic chance of being implemented and preserved afterwards?

There does not have to be a large modernization program. Small changes can matter. What matters is whether a viable space for change exists at all.

The second part is more personal.

Do you want to invest the energy required? Do you want to have the technical, business, and organizational discussions that come with it? Is this system important enough to your role? Does this kind of work fit what you want to do professionally?

There is no universal answer.

And good developers are not required to answer the first question with “yes” and the second with “of course.”

Changing the situation, consciously accepting it, and leaving it can all be equally legitimate professional decisions depending on the context.

Change it, like it or leave it

The title of this article sounds harsher than the three options are meant to be.

They are not a threat. They are not a management slogan and they are not a complete decision theory.

They are simply names for three fundamentally different personal attitudes toward a reality that you can only partially control.

Change it

If meaningful change is realistically possible and you consciously choose to pursue it, you can work on it.

“Change it” does not mean working harder, pulling more responsibility onto yourself, or becoming the next person without whom nothing works.

The more important task is to change the conditions under which the system continues to evolve: build allies, establish shared architecture guidelines, protect business behavior, distribute knowledge, and carry out controlled reconstruction where it is technically and economically sensible.

Change it does not mean making the system more dependent on you. Good change does the opposite: it reduces that dependency.

Like it

Like it does not mean approving of poor architecture.

It means consciously accepting the constraints that exist.

Perhaps the product is close to retirement. Perhaps there is no viable business case for a broader reconstruction. Perhaps the organization has deliberately prioritized other investments. Perhaps your own role simply does not provide enough room to act.

In that case, a professional decision can be:

I understand the limits of this system, and I will work as professionally as possible within that reality.

Acceptance is not the same as resignation. It can mean deciding not to reopen a structural conflict every day after the organization has already made its decision, and focusing your work on what is realistically possible within the existing constraints.

That acceptance still has to remain sustainable for the individual. If it turns into persistent cynicism, complete disengagement, or a level of strain that no longer feels acceptable, then “Like it” may no longer describe the situation particularly well.

Leave it

Sometimes three things remain incompatible over time: the technical reality of the system, the organizational conditions around it, and your own idea of how you want to work professionally.

If meaningful change is not realistically possible and conscious acceptance is not sustainable either, leaving a project, a team, a role, or an organization can be a legitimate professional decision.

That is neither automatically the right decision nor a judgment on the people who stay. It is not a defeat either.

Not every problem you can recognize has to become your personal life project.

All three options are legitimate

It would be tempting to turn the three possibilities into a hierarchy.

“Change it” would become the courageous choice. “Like it” the weak one. “Leave it” the failure.

That would be the wrong conclusion.

All three can be rational and professional depending on context.

Someone taking responsibility for a strategically important product with a genuine mandate to change it may have very good reasons to choose “Change it”.

Someone professionally operating a system with a limited remaining lifetime until its planned replacement may be supporting exactly the right business decision by choosing “Like it”.

And someone working permanently in an environment whose constraints can neither be changed nor reconciled with their own professional expectations may have good reasons to leave it.

People also do not have to remain in one category forever.

“Change it” may be right today and “Like it” may become sensible two years later because the economic situation has changed. Conversely, an organization that consciously tolerated a condition for a long time may later create a genuine mandate for change.

The quality of the decision does not depend on which of the three options is chosen. It depends on whether the choice consciously fits the situation that actually exists.

When the person and the organization have chosen different options

The situation can become especially difficult when your own decision and the organization’s de facto decision do not match.

An organization may already have consciously — or at least effectively — accepted a Big Ball of Mud.

It knows the higher change costs. It knows the existing risks. It knows that certain experts are required. It may have considered several options and decided that a larger reconstruction will not be funded for now.

From its perspective, the answer is essentially:

Like it.

That does not have to mean enthusiasm for the architecture. It may simply mean that the organization is willing to carry the known disadvantages because other investments currently matter more.

An individual architect may meanwhile continue to work in “Change it” mode every day.

They write another concept. They prepare another analysis. They explain the dependency structure again. They use the next feature as an opportunity for refactoring. They try one more time to formulate a business case. They hope that the next, better explanation will finally create the mandate that has been missing.

Each of those activities may be sensible in isolation.

The problem is the long-term mismatch.

It becomes problematic when you spend years believing that you have chosen option one while the organization chose option two long ago.

At that point, the person is no longer only working on a difficult technical change. They are simultaneously trying to reverse an organizational decision, possibly without the authority required to do so.

That can create substantial frustration over time without the person necessarily being technically wrong or the organization necessarily being right.

Both sides can assess the same system accurately and still reach different conclusions about how much change is economically, organizationally, and personally worthwhile.

That is precisely why these levels have to be kept separate.

Sometimes the missing ingredient is not a better architecture argument.

Sometimes the decision has already been made at another level.

No advice from a distance

This article cannot decide which of the three options is right for a specific project.

Systems, organizations, and personal situations differ too much for that.

There is no useful rule such as:

If management rejects refactoring three times, you should leave.

Nor would either of these be useful:

A good architect keeps fighting until the organization changes.

or:

Anyone who accepts a legacy system has given up.

The three options are not a checklist and not a score.

They merely provide language for a decision that can otherwise remain surprisingly vague.

Do I want to change this reality?

Do I want to work consciously within this reality?

Or do I no longer want to be part of this reality?

The answers depend on the product, the actual room for action, the economic context, and your own priorities.

The end of this series

This series began with a system whose architecture can be remarkably difficult to discuss openly.

At the beginning stood the picture of an organization where dangerous areas are known, experienced people safeguard particular changes, and yet the recurring question is why development has become so slow.

Since then, we have looked at the Big Ball of Mud from different directions.

We have seen that it is not a synonym for a monolith. That it can emerge from many locally understandable decisions. That its boundaries can gradually lose their effect. That small business changes can open large understanding surfaces. That its problems can be difficult for stakeholders to see. That organizations help shape architecture. That key individuals can be both solution and risk. That people adapt to the working environment that emerges. That poor changeability can become economically significant without automatically justifying reconstruction. And that reconstruction should not become the next hero story.

There is therefore no simple technical punchline at the end.

A Big Ball of Mud can work and create economic value. It can produce exceptional experts and lead organizations to develop remarkably effective compensating mechanisms. It can frustrate people or give them an environment in which their particular experience becomes enormously valuable. It can become expensive and difficult to plan, be reconstructed or replaced — and it can continue to exist for many years.

Architecture does not decide this on its own. People and organizations decide with it.

Conclusion

A Big Ball of Mud is not a state in which nothing works.

Perhaps that is the most important insight of this series: systems like these can survive for a long time because developers learn to understand them, experts compensate for uncertainty, tests and processes absorb risks, organizations adapt their ways of working, and stakeholders continue to derive real value from them.

That does not make their structural condition irrelevant, but it does explain why that condition can become remarkably stable.

A Big Ball of Mud is a socio-technical phenomenon.

Technology, organization, economics, and people cannot be cleanly separated within it. Code affects work. Work compensates for code. Economic decisions determine room for action. Organizational structures shape technical decisions. People learn how to operate the system that emerges from all of this.

You can try to change that reality. You can consciously accept it. Or you can decide not to remain part of it. None of these choices is automatically right. What matters is whether the choice fits the situation that actually exists and your own priorities.

You can understand the reality of a system. But you still have to decide what role you want to play in that reality.

Change it, like it or leave it.

Perhaps the most important insight of this series is therefore not how to recognize or reconstruct a Big Ball of Mud. Perhaps it is that technical insight does not automatically create a personal obligation.

Not every system has to be rescued by you — and not every system has to be rescued at all.

In the end, there is no universal technical answer. There is a conscious decision about which reality you can change, which reality you are willing to accept — and which reality you should leave.