But It Works

The software runs.

It does more than run. It looks good. Customers log in. Business processes work. The dashboard loads. Another feature has shipped. There may be monitoring, CI/CD, automated tests, Sonar, and a modern user interface. Releases happen. Contracts are fulfilled. Revenue depends on this system. And then an architect says:

“We have a serious structural problem.”

The obvious question is:

How can something be broken if it works?

With a building, that contradiction is easier to resolve. Cracks in the walls, moisture, corrosion, settlement, or damaged load-bearing elements are at least observable in principle. You do not need to be a structural engineer to understand that a broken beam is a problem. Software does not offer that kind of visibility.

A deteriorating building shows cracks. A deteriorating software system still shows the login screen.

It is not a perfect analogy. A software system is not a building, and code changes in different ways than concrete or steel. But the analogy makes one important difference visible: structural problems in software do not have to destroy the system’s immediately observable value. That is exactly why a Big Ball of Mud can be harder for a stakeholder to recognize than it may seem to a developer. The previous article in this series focused on a technical question:

Where can I stop thinking about this change with reasonable confidence?

This article changes perspective. Not: What does the developer see? But:

What does the stakeholder actually see?

Two properties of the same system

A product owner, project manager, or client first evaluates a system through entirely legitimate questions:

• Does the business process work?
• Can customers do their jobs?
• Is the application available?
• Are requirements being delivered?
• Are contracts and delivery commitments being met?

The architect also looks at other properties:

• Can changes be bounded reliably?
• Are responsibilities clear?
• Are dependencies understandable and directed?
• Is relevant knowledge local, or spread across the entire system?
• Can multiple teams work independently?
• How much of the system has to be understood to make a local change safely?
• How large can a change’s regression surface become?
• Will these properties still hold after several more years of development?

Both perspectives describe the same system. They simply answer different questions.

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

That resolves the apparent contradiction from the beginning. The stakeholder’s statement — “The system works” — can be correct. The architect’s statement — “We have a structural problem” — can be correct at the same time. The conflict is not between reason and irrationality. It is between two different kinds of evidence.

Functional stability and structural changeability are two different properties of a software system.

The stakeholder sees the value. The architect also sees the slope

The difference is also a difference in time horizon. A stakeholder needs to know what the system delivers today. Customers do not wait for future architectural quality. Budgets apply to concrete periods. Contracts have deadlines. Features matter to markets or projects. The architect cares about that current state as well. But they also watch how the system behaves under change. As a metaphor, you could say:

The stakeholder sees the current value. The architect also sees the slope.

That slope is not an empirically defined curve that must rise monotonically year after year in every project. The idea is simpler: structural erosion may show up less in today’s output than in the trajectory of future change costs. A change suddenly requires more exploration. A release needs more safeguards. More areas can be affected by a local change. Certain people have to be consulted more often. Two functionally independent teams collide technically. New employees need longer before they can make changes safely.

None of these observations means the system will necessarily collapse tomorrow. That is precisely the problem. The software can continue to perform its purpose reliably while its ability to respond to future requirements becomes progressively harder to predict. The system works today, while the architect is warning about the costs and risks of tomorrow.

The measurement problem in software development

For a decision-maker, this creates a practical problem: How do you evaluate something that is only indirectly visible? Many measurement logics familiar from traditional manufacturing and management accounting transfer only imperfectly to software development. Industrial manufacturing is, of course, complex as well. Yet it often has comparatively stable and physically observable quantities:

• units produced,
• throughput,
• scrap,
• material consumption,
• machine runtime,
• unit cost,
• margins.

In many manufacturing processes, output can be translated into comparatively stable units. Production volumes, material consumption, or scrap can be observed under defined conditions and compared over time. In software development, the difficulty starts with the question of what should count as a unit of output at all: a feature, a closed ticket, a story point, a new API, a line of code, business value, a production incident that never happened, a successful migration, or a week spent simplifying existing code. None of these is, by itself, a stable equivalent of the “unit” familiar from manufacturing.

The input is not stably comparable either. Two developer-hours are not automatically two identical economic production units. The effort required depends on existing knowledge, the codebase, team structure, tooling, domain complexity, external dependencies, and the existing architecture, among other things. A universal benchmark such as

“A settings dialog takes an industry average of 13.7 developer-hours”

would therefore make little sense. Research on software productivity reflects this problem. Petersen’s systematic map and review shows how differently software productivity has been measured and predicted. The later SPACE framework makes the issue even more explicit: developer productivity is multidimensional and cannot sensibly be reduced to a single activity metric. Its dimensions include satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. That matters for the architecture question.

Software development absolutely does have useful metrics. Availability, defect rates, lead time, or deployment frequency can make important properties of a system and its delivery process visible. The problem is not that software is inherently unmeasurable. The problem is that none of these metrics directly tells us how much additional change work is caused by a particular internal structure.

If software productivity as a whole does not have one stable unit of output, isolating the productivity effect of a structural property that is difficult to observe directly becomes even harder.

Slow — compared with what?

Suppose a feature takes six weeks. Is that slow? Perhaps the domain requirement was unusually complex. Perhaps the requirements remained unclear for a long time. Perhaps the team was waiting for an external vendor. Perhaps the responsible developer was still unfamiliar with that area. Perhaps the original estimate was simply wrong. Perhaps the application was so structurally coupled that a small change required large parts of the system to be understood, modified, and tested. The directly observable fact is only:

The feature took six weeks.

What the organization lacks is the counterfactual. How long would exactly the same requirement have taken with the same team, the same customers, the same domain constraints, and the same quality expectations in a differently structured codebase? That second system usually does not exist.

Software performance problems often have no visible counterfactual.

We can see how expensive a change was in our system. We cannot see how expensive the same change would have been in a structurally healthy comparison system. That differs, for example, from a production step in which two machines can be compared under sufficiently similar conditions. This is also why a developer can be completely convinced that a change was “far too expensive” while a stakeholder has no unambiguous comparison baseline. Both can reason sensibly from the evidence available to them.

Software has no simple per-unit cost model

The problem becomes even clearer when activity is confused with outcome. A developer can delete 2,000 lines of code and create enormous value. Another can add 10,000 lines and make future changes more expensive. A team can spend a week without shipping a single visible feature and remove a recurring technical obstacle that would otherwise have generated work for years. Another team can close ten tickets while introducing additional coupling that only becomes visible during later changes.

Activity is not the same as productivity, and output volume is not automatically business value.

The SPACE framework explicitly warns against this confusion: activity metrics can make one dimension of work visible, but they should not be interpreted as a complete measure of individual or organizational productivity. For stakeholders, that creates an uncomfortable control problem. Money can be measured very precisely. Headcount can be measured precisely. Working time can be measured precisely. The sustainable changeability produced by that investment is much harder to translate into one number.

Architecture makes the measurement problem even harder

Architecture adds another layer to the problem. Its value often does not appear as an additional feature that is visible today. It may mean that a future change touches only three files instead of twelve. That a developer can understand one domain slice without first analyzing five global services. That two teams can actually work independently. That a defect remains contained within a bounded area. That a new requirement does not depend on one specific employee who is the only person who knows the historical side effects. Or simply that a whole class of problems never emerges.

Good architecture often produces no visible output. It prevents invisible extra work.

Its economic value therefore partly lies in an event that did not happen. A complicated regression test was not necessary. A three-week investigation was not necessary. A coordination meeting involving four teams was not necessary. A production incident did not occur. A change did not have to be reviewed by one of the last two system experts. That is valuable — but difficult to observe.

The value of good architecture often lies in problems that never happen.

This does not mean that every architecture investment makes economic sense. Refactorings can also be unnecessary, poorly prioritized, or riskier than the existing state. The measurement problem remains: the investment cost is immediately visible. A substantial part of the possible benefit consists of future work that will never need to happen.

The asymmetric business case

A new feature often has a comparatively easy-to-communicate business case: there is scope and a customer request, perhaps also a deadline, a contract, or expected revenue. Architecture work looks different from a decision-making perspective. Its costs occur today while developers are not working on other features; a migration can introduce defects, and a restructuring can put a release at risk. The benefit, by contrast, may not appear until the next ten, fifty, or hundred changes — and a substantial share of that benefit consists of costs that then never occur and therefore remain unobserved. That creates a fundamental asymmetry:

A stakeholder does not necessarily reject architecture work because they do not understand technology. They may reject an investment whose costs are certain and whose benefits are difficult to measure.

For someone responsible for real budgets, real customers, and real delivery commitments, that skepticism is not surprising. The opposite would be more surprising.

Organizations can only manage what they can observe. Structural change costs, however, are often visible only indirectly.

“But it works” is real evidence

It would be too easy to dismiss “But it works” as an excuse. The fact that the system works is real evidence: customers can work, revenue is being generated, and business-critical processes are running. Perhaps the system has met its availability targets for years or has just completed another successful release. Those observations have to be taken seriously; they simply do not answer every relevant question.

“It works” answers the question of functional correctness. It does not automatically answer the question of structural changeability.

Stable operation does not mean the next change will be cheap. A successful release does not mean two additional teams can develop independently. A professional user interface does not mean state ownership is clear. And ten years of successful operation do not mean that relevant knowledge is sufficiently encoded in the system itself.

Conversely, an architect’s warning does not automatically mean the architect is right. Technical experts can overestimate risks, misjudge alternatives, or mistake their own preferences for economic necessity. The stakeholder therefore sits between two incomplete information sets: the working system is visible, while the structural damage is initially a diagnosis.

More people do not automatically solve the problem

A classic response to capacity constraints is to buy more capacity — through additional machines, extra shifts, or more staff. That can work in software development too. A well-structured system can benefit substantially from additional developers and teams. But additional developers create additional independent development capacity only when enough work can actually be carried out independently. In a heavily entangled system, that can become difficult. New developers first have to understand large parts of the overall system, multiple teams change the same global state, shared services become conflict points, and changes have overlapping regression surfaces. At the same time, the same few experts are needed for reviews and questions while functionally independent requirements collide technically. That changes the capacity equation.

The system has too few independent change spaces to translate additional developers fully into independent productivity.

Software-engineering research has examined the connection between technical dependencies and organizational coordination for a long time. Based on empirical project analysis, Cataldo et al. articulate the fundamental relationship that task dependencies create coordination requirements. MacCormack, Baldwin, and Rusnak also found strong relationships between product architecture and organizational structures — the so-called mirroring hypothesis. Neither study justifies a simple causal formula, but together they help explain why technical modularity and organizational independence cannot be treated as completely separate concerns.

Coordination cost is not a special property of a Big Ball of Mud. Even in well-modularized systems, productive capacity does not grow linearly with every additional developer. The point here is narrower: when technical boundaries no longer separate functionally independent work reliably, additional people can encounter the same dependencies, knowledge bottlenecks, and regression surfaces. Structural entanglement can therefore amplify coordination costs that already exist. In less formal terms:

At some point, you cannot simply throw more developers at the problem.

Not because additional people are inherently useless. But because additional people create additional communication and coordination while the number of independently workable change spaces may barely increase.

Good architecture therefore does more than support technical scalability. It can enable organizational parallelism because functionally separate changes can actually be worked on separately. That is not an argument for microservices, microfrontends, or any other particular architecture style. The more fundamental question is: Can changes happen independently?

Additional development capacity helps only to a limited extent if the system does not provide enough independent work areas.

More developers, barely more throughput

For a stakeholder, this mechanism becomes visible only through its effects. Suppose an organization employs ten developers. Product development grows, so it hires ten more. The cost of that decision is easy to observe. The additional personnel cost is immediately visible and comparatively easy to quantify. Feature throughput, however, does not have to come close to doubling. Perhaps it increases far less than expected. The organization needs an explanation. There are many plausible explanations for the lower throughput: perhaps the wrong developers were hired, recruiting is not working, there are too many meetings, leadership is lacking, requirements have become more difficult, or the new employees simply are not fully onboarded yet. Any of these explanations can be correct in a particular case. But there is another possible explanation: The additional developers compete for the same technical bottlenecks, depend on the same experts, and modify the same global structures. As the number of simultaneous changes rises, so does the number of possible overlaps. The organization has increased its people capacity without a corresponding increase in independently workable change spaces. From the outside, that does not initially look like architecture. It looks like a productivity problem.

“Those were just better developers”

Individual productivity is equally difficult to interpret. A developer has worked on the system for eight years. They know historical decisions, unusual side effects, hidden dependencies, and the places that are better left untouched. They complete a certain class of tasks comparatively quickly. Then they leave the company. Their successors need significantly longer for similar changes. One plausible explanation is:

“The previous developers were simply better.”

That can be true. Experience and individual skill obviously matter. But there is a second hypothesis. Over many years, the long-serving employee built a mental model that compensated for missing explicit structure in the system. They did not just know what the code contained. They knew which parts belonged together despite their names, which dependency existed for historical reasons, and which apparently local change would have consequences somewhere else entirely. The organization may then be measuring something else under the label of individual productivity: the amount of implicit system knowledge one person accumulated over years.

What looks like exceptional individual productivity can partly be the ability to compensate for structural weakness with exceptional system knowledge.

That does not make the earlier performance any less real, but it changes the diagnosis of why another person cannot simply replace it.

The KPI vacuum

If structural quality is difficult to observe directly, an organization still has to manage. It therefore relies on quantities that are available and can be measured repeatedly: tickets, velocity, lead time, deployment frequency, defect counts, code coverage, Sonar issues, budget, or headcount. These metrics are not inherently bad; many answer important questions. The problem begins when an easily measurable proxy becomes the complete description of a structural problem that is much harder to measure.

A particularly illustrative statement is:

“We have Sonar now. Fix the Sonar issues.”

SonarQube can provide valuable static-quality information. The interesting point is therefore not the tool itself, but the different organizational usability of two kinds of statements. An architect might say:

“We have structural boundary erosion, unclear ownership, and changes whose effects are hard to bound.”

That immediately creates a translation problem: How much of it do we have, how do we know whether it is improving, and what target value would even belong on a management dashboard? A tool, by contrast, might report:

8,432 issues.

That number can be captured, compared, reported, placed on a dashboard, and given a target. This makes the proxy organizationally attractive even when it represents only part of the underlying structural problem.

Organizations need observable quantities in order to make decisions. Architectural problems, however, are often observable only indirectly.

What is easy to measure is therefore not automatically what matters most. The caution applies in the other direction as well: lead time, deployment frequency, or defect counts should not be dismissed simply because they are not complete architecture metrics. They describe real properties of the system and its delivery process — they simply do not tell the whole story.

Every symptom has a local explanation

This creates another difficulty. A Big Ball of Mud does not necessarily produce one unambiguous symptom labeled:

“Cause: missing system structure.”

Instead, an organization sees many separate events: features take longer than expected, releases become frustrating, firefighting and customer escalations recur, a team seems resigned, particular experts are constantly needed, new employees take a long time to onboard, additional headcount produces less throughput than expected, or people leave the company. Each event has a plausible local explanation — from a poor hiring fit or recruiting problem to leadership, unclear requirements, difficult customers, slow QA, or unsuitable processes.

Again, any one of these explanations can be correct. The systemic risk is not that local explanations are inherently wrong. It arises when every symptom is explained only locally and nobody asks whether several of those observations might share a structural cause.

A systemic problem can remain invisible for a remarkably long time when every symptom has a plausible local explanation.

Lost in translation

There is also a communication problem. The stakeholder says:

“We need the feature by October.”

The architect replies:

“We would really need to stabilize state ownership and slice boundaries first.”

Both statements can be factually correct. They simply belong to different causal models. The stakeholder tends to describe the situation in terms of cost, benefit, deadlines, contracts, customers, and risk; the architect uses coupling, responsibilities, change radii, dependencies, regression, and long-term changeability. The difficulty is not that one side “understands the system” and the other does not.

Technical and business leaders observe the same system through different models.

Business–IT alignment research has examined exactly this interface for decades. Luftman, Lyytinen, and Ben-Zvi describe alignment not as one technical capability but through dimensions including communication between IT and business, collaborative governance, partnership, and the ability to understand and assess IT value. Their work draws on a large cross-organizational dataset and, precisely for that reason, illustrates that alignment involves far more than the technical quality of a system.

Recent research on technical debt shows the same need for translation more concretely. Wiese and Borowa studied the perspective of IT managers through 16 semi-structured interviews and an additional focus group. Participants generally understood technical debt and considered its management important. Their challenges included communicating about technical debt, establishing a systematic management process, and dealing with old systems that continued to deliver business value despite substantial legacy burdens. The authors therefore propose, among other things, a model intended to make chains of causes and consequences of technical debt more visible to business stakeholders.

That is a notable finding. The problem is not necessarily an unwillingness to take technical quality seriously. Even establishing a shared view of the problem is difficult.

Stakeholders and architects see the same system. They observe different properties and different time horizons.

When technical warnings lose their signal value

Communication can be made harder by another kind of experience. Over the course of a project, a stakeholder may hear statements such as “That is technically impossible” — only to see it become possible later. Perhaps they are told that a refactoring must happen before a feature can be built, and the feature gets built anyway. Or someone warns that the system “cannot keep going like this much longer,” while it is still running three years later. A comprehensible organizational learning pattern can emerge from this. Technical warnings may eventually be understood not only as forecasts, but also as part of prioritization or resource negotiations. That does not mean developers deliberately exaggerate. Nor does it mean a stakeholder fundamentally distrusts technical statements. But warnings have a communication history.

If earlier statements were phrased too absolutely and the predicted event did not occur, the next serious warning can become harder to distinguish from an earlier cautious, interest-driven, or simply incorrect forecast. A Big Ball of Mud makes this problem worse because the warning is rarely as concrete as “The system will fail on October 17.” More often it sounds like: “Future changes are becoming increasingly risky.” That kind of statement is much harder to falsify — and much harder to prove.

Change carries real risk

Up to this point, it might seem as though the organization merely needs to recognize the structural damage correctly. But even then, the conflict does not disappear. The architect sees the risks of the status quo; the stakeholder must also account for the risks of change. Customers still have to work during a major restructuring, revenue and contracts continue, and regulatory obligations do not disappear. At the same time, a migration can fail, a refactoring can introduce regressions, features may have to be postponed, and budgets remain finite. A major restructuring or rewrite can take months or years — with no guarantee of success of its own.

The status quo has known problems. Change has unknown problems.

The architect is therefore not proposing an exchange of risk for safety. They are often proposing an exchange of one known risk for another kind of risk. That changes the evaluation fundamentally. From a technical perspective, a system may be obviously hard to change.

From an economic perspective, continuing to operate a known business-critical system can still be rational as long as the risks of the alternative cannot be assessed with sufficient confidence.

Too big to fail — without the financial-crisis analogy

In particularly large legacy systems, this creates a paradox. Such a system may have grown for decades, integrate many other systems, implement central business processes, serve thousands of customers, and encode regulatory requirements. Precisely for that reason, strong structural changeability would be especially valuable. At the same time, the very same business criticality makes deep structural change especially risky.

The more important a system is, the more valuable its structural health would be — and the greater the immediate risks of deep structural change can become at the same time.

“Too big to fail” is not meant here as a direct analogy to the financial crisis. It simply describes this organizational constraint: a system can become so important that even recognized structural problems do not automatically justify a deep intervention.

Only now do psychological mechanisms enter the picture

Up to this point, the explanation requires neither irrationality nor ignorance, hostility toward change, or psychological bias. The decision is already difficult on purely economic grounds:

• Today’s value is visible.
• Structural damage is only indirectly observable.
• There is no counterfactual.
• The costs of change are real.
• Part of the benefit consists of future costs that are avoided.
• The alternative carries its own risks.

Only on top of this already uncertain decision can additional psychological and organizational mechanisms act. A classic example is status quo bias. Samuelson and Zeckhauser showed systematically that existing options are selected disproportionately often in decision situations. That does not mean every decision to keep a legacy system is irrational. It only means that the existing state can influence the decision in its own right.

The sunk cost effect is related. Arkes and Blumer described an increased tendency to continue an endeavor after money, time, or effort has already been invested. Again, this does not turn every long-lived legacy system into an irrational case of sunk-cost thinking. Even more care is required with escalation of commitment.

Continuing to operate an old system is not automatically escalation of commitment. The concept becomes relevant when negative feedback is present and commitment to a problematic course of action continues or increases.

Berente et al. analyzed 15 published cases of escalated large-scale information-systems projects. Their qualitative meta-analysis shows that persistence cannot be reduced to an individual decision error. Institutional logics and justifications can change over the life of a project and help sustain continued commitment. Earlier work by Keil et al. likewise studied escalation behavior specifically in software projects as an organizational decision problem. This research does not explain why a Big Ball of Mud emerges or why a particular stakeholder rejects a particular change. It shows something narrower:

A decision that is already difficult to evaluate can be shifted further toward continuation of the existing course by known decision and organizational mechanisms.

Defensive routines instead of “they just do not want to see the problem”

The situation becomes even more difficult when a structural problem touches questions of responsibility. A structural diagnosis quickly raises uncomfortable follow-up questions: Why was the system developed this way for years, why do we suddenly need more people, why do changes take so long, why are experienced employees leaving, and why was the problem not addressed earlier? These are not neutral questions. They can touch decisions, responsibilities, and professional identity.

Organizational research uses the concept of defensive routines for recurring patterns through which individuals or organizations deal with threatening or conflict-laden situations.

A recent two-year ethnographic action-research study by Auqui-Caceres and Furlan examines why such defensive routines persisted in one company. In the context they studied, the authors distinguish patterns including blaming external forces, evading authentic dialogue, and avoiding direct confrontation. As a qualitative study of one organizational setting, the paper is not a diagnostic checklist for other companies. But it provides useful language for patterns that might otherwise be interpreted too quickly as individual weakness. Statements such as “They were not that good anyway,” “Recruiting really messed that up,” or “As a team lead, you need to motivate people better” can be completely correct in an individual case. A recruiting process can be poor. An employee can be a poor fit for a task. Leadership can be insufficient. The problem begins when a recurring pattern of local explanations systematically prevents a possible shared structural cause from being considered at all. The same applies to what one might colloquially call “smiling problems away.”

An organization can normalize strain, positively reframe difficulties, defuse conflict, or defend earlier decisions. In the short term, all of that can even be functional. Organizations have to remain operational and cannot turn every warning into a strategic crisis. Over time, however, the same ability can help a problematic state become normal.

Visible goals compete with invisible structure

These mechanisms meet another organizational reality. Leaders in large organizations are often measured against visible outcomes such as budget, deadlines, headcount, releases, revenue, customer targets, and operational stability. These quantities are not superficial. They are central to running an organization. Architectural quality competes with them for attention even though it is much harder to observe and report directly.

Architectural quality competes with quantities that are more immediate, more visible, and easier to report.

Technical-debt research also shows that such decisions are not made on technical grounds alone. A recent qualitative TOSEM study by Bittencourt et al. examines which value criteria shape decisions to deliberately incur technical debt, based on interviews with eleven experienced software practitioners. The identified criteria include not only technical concerns but also relationships with customers and stakeholders, temporal and delivery pressure, cognitive and framing effects, and organizational and political conditions. The small qualitative sample does not support a universal decision model, but the study illustrates how deeply such decisions are embedded in real organizational trade-offs.

Besker, Martini, and Bosch likewise studied management strategies and incentive structures around technical debt. The existence of this line of research already shows why technical debt cannot usefully be treated as a purely technical property of code. It is also a question of which consequences become visible, who has decision authority, and which objectives the organization prioritizes. That explains why “architecture is important” is not a sufficient organizational argument. The competing concerns are important too.

When the disagreement disappears

Over time, another effect can emerge. At first, a developer might say, “We need to talk about this.” Later it becomes, “We have raised this several times already.” Eventually, all that remains may be: “Just implement the ticket.”

From the outside, this can look as though the situation has calmed down: there are fewer discussions, architecture issues escalate into meetings less often, and resistance to new requirements decreases. The system appears organizationally more stable. Less disagreement, however, is not an unambiguous signal.

Less disagreement does not automatically mean fewer problems. Sometimes it only means less voice.

Research on employee silence examines exactly this distinction between problems that exist and the willingness to speak about them. Hao et al. analyzed 168 independent samples with more than 63,000 participants in a meta-analysis. The results show employee silence as a distinct organizational phenomenon with a range of antecedents and outcomes; psychological safety is among the factors that matter.

There is now also more specific research in software development. Sánchez-Gordón et al. studied voice and silence in software-development teams using 158 valid survey responses and structural-equation modeling. In their sample, psychological safety was more strongly related to silence than to voice; voice and silence were also related differently to task performance and withdrawal behavior. The paper appears in the 2026 volume of Information and Software Technology and was published online in 2025. These are observed relationships, not evidence that a particular architecture directly causes silence. For the perception of a Big Ball of Mud, however, one simple consequence matters:

A stakeholder can react only to information that reaches them. If technical warnings lose their effect over years and are then voiced less often, the organization can receive a misleading signal of stability.

And then people leave

Turnover is not an unambiguous architecture indicator either. People change companies for many reasons: the market may pay better, expectations or roles may not match, leadership may be difficult, private priorities may change, or recruiting may genuinely have made a mistake. So the statement

“The Big Ball of Mud causes people to resign”

would be far too strong. But a cluster of dissatisfaction, reduced voice, concentrated knowledge, difficult onboarding, and turnover can be part of a broader socio-technical problem.

Knowledge loss becomes particularly problematic where the system’s structure itself provides little orientation. If someone with extensive implicit system knowledge leaves, the organization loses more than development capacity. Part of the invisible navigation system can disappear with them. The successor sees the same codebase. They do not have the same map. From the outside, that event can easily look like an individual staffing problem. Perhaps it is. Perhaps it is also structural.

There is no obvious villain here

That leaves an uncomfortable conclusion. The developer can sincerely believe their technical diagnosis. The architect can see real structural damage. The product owner can simultaneously have a real delivery commitment to meet. A department head can be responsible for a limited budget. A client can reasonably expect that a functioning system will not undergo deep restructuring without a solid case. Management can make an understandable decision under incomplete information. And the overall system can still remain trapped in a bad equilibrium. None of this requires ignorant stakeholders, incompetent managers, lazy developers, or malicious architects.

Different information sets, different time horizons, real economic risks, and a system whose most important structural properties are only indirectly visible are enough. Psychological and organizational mechanisms can then stabilize that situation. But they do not create the original conflict.

The problem is not obvious

For a developer, a Big Ball of Mud can be experienced directly as a structural problem. They open a ticket and first have to determine which of several services is actually responsible, discover additional writers while changing a local state, fix regressions in areas that are unrelated from a domain perspective, or wait for the only colleague who understands a particular part of the system. For them, the architecture problem is immediately real. The stakeholder, by contrast, sees a functioning asset whose operational problems initially appear separate: some changes take a long time, releases are difficult, teams depend on particular experts, customer escalations occasionally have to be defused, new employees become productive more slowly than expected, and additional headcount creates less throughput than hoped. None of these observations proves an architecture problem on its own. Each has plausible alternative explanations.

And now this stakeholder is expected to spend real money, postpone features, and accept real project risk in order to address a technical cause whose damage is visible only indirectly and whose avoided future costs are hard to prove.

Resistance to change is not automatically a lack of insight. It can be a rational response to a problem whose costs are visible, whose cause is hard to observe, and whose alternative carries substantial uncertainty.

Status quo bias, escalation of commitment, defensive routines, and employee silence can amplify that situation. But they do not by themselves explain why change becomes so difficult. The conflict begins earlier: with the question of what an organization can actually see and measure.

The system runs. That is exactly what makes it so difficult to explain why it is still a problem.

Research literature

• Arkes, H. R. & Blumer, C. (1985): The Psychology of Sunk Cost. Organizational Behavior and Human Decision Processes, 35(1), 124–140. DOI: 10.1016/0749-5978(85)90049-4.
• Auqui-Caceres, M.-V. & Furlan, A. (2026): Why do defensive routines persist in organizational contexts? Results from a two-year ethnographic action research. European Management Review. DOI: 10.1111/emre.70055.
• Berente, N., Salge, C. A. de L., Mallampalli, V. K. P. & Park, K. J. (2022): Rethinking Project Escalation: An Institutional Perspective on the Persistence of Failing Large-Scale Information System Projects. Journal of Management Information Systems, 39(3), 640–672. DOI: 10.1080/07421222.2022.2096545.
• Besker, T., Martini, A. & Bosch, J. (2022): The use of incentives to promote technical debt management. Information and Software Technology, 142, 106740. DOI: 10.1016/j.infsof.2021.106740.
• Bittencourt, J. P., Spínola, R. & Maciel, R. S. P. (2026): Stakeholder Value Criteria for Technical Debt Acquisition Decisions: An Empirical Analysis. ACM Transactions on Software Engineering and Methodology. DOI: 10.1145/3808227.
• Cataldo, M., Wagstrom, P. A., Herbsleb, J. D. & Carley, K. M. (2006): Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools. Proceedings of CSCW 2006. DOI: 10.1145/1180875.1180929.
• Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B. & Butler, J. (2021): The SPACE of Developer Productivity: There’s more to it than you think. ACM Queue, 19(1), 20–48. DOI: 10.1145/3454122.3454124.
• Hao, L., Zhu, H., He, Y., Duan, J., Zhao, T. & Meng, H. (2022): When Is Silence Golden? A Meta-analysis on Antecedents and Outcomes of Employee Silence. Journal of Business and Psychology, 37, 1039–1063. DOI: 10.1007/s10869-021-09788-7.
• Keil, M., Tan, B. C. Y., Wei, K. K., Saarinen, T., Tuunainen, V. & Wassenaar, A. (2000): A Cross-Cultural Study on Escalation of Commitment Behavior in Software Projects. MIS Quarterly, 24(2), 299–325. DOI: 10.2307/3250940.
• Luftman, J., Lyytinen, K. & Ben-Zvi, T. (2017): Enhancing the measurement of information technology (IT) business alignment and its influence on company performance. Journal of Information Technology, 32(1), 26–46. DOI: 10.1057/jit.2015.23.
• MacCormack, A., Baldwin, C. & Rusnak, J. (2012): Exploring the duality between product and organizational architectures: A test of the “mirroring” hypothesis. Research Policy, 41(8), 1309–1324. DOI: 10.1016/j.respol.2012.04.011.
• Petersen, K. (2011): Measuring and predicting software productivity: A systematic map and review. Information and Software Technology, 53(4), 317–343. DOI: 10.1016/j.infsof.2010.12.001.
• Samuelson, W. & Zeckhauser, R. (1988): Status quo bias in decision making. Journal of Risk and Uncertainty, 1, 7–59. DOI: 10.1007/BF00055564.
• Sánchez-Gordón, M., Colomo-Palacios, R., Sanchez Gordon, A. & Hubin, A. (2026): The role of voice and silence behaviors in software development: a structural equation modeling analysis. Information and Software Technology, 190, 107972. DOI: 10.1016/j.infsof.2025.107972.
• Wiese, M. & Borowa, K. (2023): IT managers’ perspective on Technical Debt Management. Journal of Systems and Software, 202, 111700. DOI: 10.1016/j.jss.2023.111700.