The Big Ball of Mud Is an Organizational Problem

The code is the smallest problem

At one particularly difficult legacy system, an extensive technical assessment was eventually carried out. An experienced Principal Architect spent a considerable amount of time analyzing the architecture, the dependencies, and the development processes. There was no shortage of technical problems to find: the system consisted of thousands of files, cyclic dependencies ran through large parts of the codebase, state and responsibilities were scattered across the system, and global mechanisms connected areas that were largely independent from a domain perspective. For many changes, it was difficult to predict which parts of the system would actually be affected.

It would have been reasonable to expect this Big Ball of Mud to sit at the very top of the problem list. It did not. The Principal Architect summarized the situation roughly like this:

“The code is the smallest problem.”

This is an experience from one specific project, not a scientific finding. Nor did the statement mean that the technical state was harmless. Quite the opposite: the architecture had eroded substantially. The code did, however, have one property that many of the other problems did not: it could be analyzed. Dependencies could be visualized, cycles identified, modules reshaped, tests added, and technical boundaries rebuilt incrementally. At least in principle, there was a technical toolkit for dealing with it. The harder question was therefore:

Which organization is supposed to sustain this change for several years?

The executive leadership of the affected business unit was operating under considerable economic and operational pressure. Product Ownership was not able to absorb the domain and organizational complexity of the existing system sufficiently; requirements sometimes reached development without enough understanding of the domain relationships and historical decisions already embedded in the software. Clear resignation was visible in parts of the development organization, while developers, technical leaders, and responsibilities changed frequently.

None of these observations explains a Big Ball of Mud on its own, and a single project cannot support a general theory of software organizations. The situation does, however, open a different perspective on architecture: a Big Ball of Mud lives in the repository, but the forces that can create and reproduce it over time do not live there alone.

The Big Ball of Mud lives in the repository — but its causes do not live there alone

Dependencies are written by developers. Developers extend shared services, introduce global state, bypass existing interfaces, or add further special cases to mechanisms that already exist. That technical responsibility does not disappear simply because deadlines, budgets, or organizational problems exist. At the same time, these decisions do not happen in a vacuum.

Imagine a team that urgently needs data from another domain area. The structurally cleaner solution would be to extend an existing interface, clarify responsibilities with another team, perhaps adjust data models, and test the change together. The alternative is a direct call to a service that already knows the required data. The first option requires coordination, the second can be finished in two days, and the release is next week. If the team chooses the direct call, a new technical coupling has been created. From an organizational perspective, the choice can still be understandable.

The wrong dependency often has a technical form and an organizational history.

This does not mean organizational pressure excuses every poor architecture decision or inevitably produces one. Different developers and teams can make different choices under the same conditions; architecture skills, experience, and technical leadership remain relevant. Organizational conditions do, however, shape the decision space. They influence which alternatives appear realistic, how expensive coordination is, which time horizons are considered, and who will later bear the consequences.

It is at this boundary between technical decision and organizational context that the Big Ball of Mud becomes a socio-technical problem. Conway’s original observation is often reduced to the catchy idea that an organization chart maps directly onto a system’s architecture. His argument was more nuanced: splitting design work creates communication and coordination relationships, and those conditions influence which system structures an organization can produce. Later research on the mirroring hypothesis and socio-technical congruence investigated this relationship empirically. Technical dependencies create coordination needs; the organization’s ability to meet those needs, in turn, affects development work and system evolution. This is not a deterministic equation between organizational chart and architecture, but it is strong evidence that the two levels cannot be considered independently.

The organization helps write the architecture even if it never writes a line of code.

Locally rational, globally expensive

One important mechanism emerges from the fact that the same architecture decision can be sensible and problematic at the same time, depending on the perspective. It may be rational for a developer because it solves the current ticket, for a team because it protects a promised release, for a business unit because an important customer is waiting for the feature, or for a project whose budget ends in three months. For the overall system, the same decision can become expensive over time.

Return to the direct dependency between two domain areas. Team A saves several days of coordination today, and the new dependency barely attracts attention. Months later, Team B needs to change its internal structure and discovers that several other areas now depend on it implicitly. Another year later, Team C is working on a migration and has to understand a coupling that nobody on the current team was present to create. The benefit of the original decision appeared immediately for Team A; the cost appears later and may be paid by Team C.

The costs and benefits of an architecture decision often occur neither at the same time nor in the same organizational place.

That separation makes long-term architecture decisions difficult. The unit that would have to pay for a clean interface today is not necessarily the unit that will benefit from it later. Conversely, the unit that saves time through a shortcut today may bear only a small fraction of its future cost.

Research on technical debt describes a similar temporal mechanism: decisions that are advantageous in the short term can make later changes more expensive. An international family of surveys with 653 valid responses from six countries identified time pressure and deadlines as the most frequently reported trigger of technical debt; commonly reported consequences included later delivery delays, reduced maintainability, and rework. Wiese and Borowa also show from the perspective of IT managers that time, budget, visibility, and management processes are important parts of technical-debt management.

That does not make the original decision automatically correct. It simply shows why “the developers should have built it properly” is an analytically incomplete explanation.

The benefit of a shortcut can be local and immediate while its structural costs appear later and elsewhere.

Three organizational logics, one technical outcome

The mechanism becomes particularly visible when three very different organizational contexts are compared. A large corporation, a startup, and an external contractor operate under different constraints and pursue different legitimate goals. Yet over time they can still arrive at surprisingly similar technical structures.

The Big Ball of Mud in a large corporation

In a large organization, leadership is not primarily evaluated on whether a dependency will still be well designed five years from now. Relevant concerns include budgets, financial targets, customers, projects, delivery capability, revenue, and operational stability. That is neither surprising nor inherently problematic: software development is not an end in itself, and architecture has to serve economic goals.

The difficulty begins when the time horizons drift apart. An architecture decision may take several years to pay off, while roles are reassigned much sooner, budgets are planned annually or quarterly, business units are reorganized, and strategic priorities change. In one business unit from the project environment described above, development leadership changed so frequently over a period of roughly eight years that the average tenure was around nine months. That is a single observation, not a claim about how development organizations in large corporations generally work. It does, however, lead to an important question:

What kind of long-term architecture strategy can emerge when the responsible role changes faster than the architecture investment can pay off?

The point is not that the individual leaders were short-sighted or did not care about architecture. The problem already exists in the different time horizons. A leader can rationally stabilize the next twelve months while the architecture needs a consistent direction over several years. When organizational responsibility changes faster than an architecture decision can deliver its benefits, a structural incentive problem emerges.

The Big Ball of Mud in a startup

In a startup, the same technical outcome can arise under almost opposite conditions. A young company may first need to determine whether a viable product exists at all, whether customers actually have the problem it wants to solve, whether they will pay for the solution, and whether funding will last long enough to reach the next stage. Under those conditions, it can be economically rational to build a solution in two weeks even if a cleaner long-term version would take six.

Technical debt is therefore not automatically a mistake. Under uncertainty, deliberately taking on technical debt can be an economic decision if there is a genuine trade-off and the short-term optimization fits the company’s current goals. Studies of software startups describe precisely this tension between scarce resources, rapid market learning, and engineering quality. The transition is particularly interesting: as companies mature, engineering goals tend to shift from time-to-market toward maintainability and sustainable product development. Klotins, Unterkalmsteiner, and Gorschek explicitly found this transition in their analysis of 88 startup experience reports.

The problem starts when the product evolves but the development logic underneath it does not. The prototype gains customers, the company grows, and a temporary implementation becomes a core product while the organization keeps developing as if it were still in the early exploration phase.

A startup can become a Big Ball of Mud when a development approach optimized for uncertainty outlives the phase in which the system was temporary.

What made the prototype successful does not necessarily keep the product healthy in the long run; an approach that was effective during exploration can become a structural burden in a later phase.

The Big Ball of Mud with an external contractor

The situation looks different again when an external service provider is involved. The contract may be perfectly clear: feature X, budget Y, deadline Z. During implementation, it becomes apparent that a structurally sound solution would first require rebuilding an existing area, adding three more weeks of work. The client points out that this work is outside the scope; the contractor then implements the agreed feature within the contracted constraints. Both sides can be acting entirely rationally.

The client manages a budget and needs a promised outcome. The contractor has a contract and must deliver its scope. An additional architecture investment whose benefit may only become visible years later cannot automatically be assigned to either party. The technical consequence can still remain in the system for a long time.

The party that would have to pay for good architecture today is not necessarily the party that will benefit from it tomorrow.

In long-lived systems, the effect can multiply. Contractor A builds the first version, contractor B extends it, contractor C takes over operations, and contractor D is hired years later to modernize it. Each party knows only part of the history; the codebase carries the technical traces of all of them.

Contracts end. Projects close. Contractors change. Dependencies remain.

Empirical work on technical debt likewise shows that its creation and management cannot be explained entirely within the development team. In an embedded case study of two systems in a Danish public-sector organization, Nielsen and Madsen showed that non-technical internal and external stakeholders also influence technical-debt decisions. More recent work on criteria used when intentionally taking on technical debt therefore considers not only technical consequences but also deadlines, stakeholder expectations, available resources, and organizational authority. Such studies do not provide a universal theory for every contractual model, but they do show that the relevant decision-making unit can be larger than the team that ultimately writes the code.

Different organizational logics can each produce locally rational decisions whose technical consequences outlive the original context.

Software often remembers longer than organizations do

Organizations change: teams merge or split, business units are reorganized, leaders change, products receive new owners, contractors leave a project and others take over. Projects end, budgets disappear, and new programs begin. The code does not automatically follow those organizational changes.

A dependency does not disappear because two teams were separated organizationally. Global state does not gain a new domain owner merely because the organization chart changed, and a workaround does not stop affecting the system because the customer who originally required it is gone. Software can therefore become a kind of sediment of earlier organizational forms.

Today’s software can still contain yesterday’s organizational boundaries.

This is a more cautious and useful reading of Conway’s Law for long-lived systems than the popular formula “org chart = architecture.” Conway argued as early as 1968 that the distribution of design work creates communication relationships and thereby influences the system designs organizations can produce. Later studies of the mirroring hypothesis found relationships between organizational coupling and product architecture. Research on socio-technical congruence focuses on whether the coordination requirements created by technical dependencies are matched by actual organizational communication and coordination.

None of these lines of research justifies the claim that a particular team structure inevitably creates a particular software architecture. People can deliberately design against those forces, and architecture can abstract or stabilize organizational boundaries. Doing so requires continuity, however, because an organization can change its structure in a meeting while the technical traces of its previous structure still have to be changed explicitly.

Software often remembers longer than organizations do.

Organizations change responsibilities, teams, and people. The software retains the technical decisions of their predecessors.

Ownership is more than a name on the organization chart

At this point, the concept of ownership becomes important. In many organizations, ownership initially looks clear: a team owns an area, a Product Owner owns a product, a lead is responsible for architecture, and a manager is responsible for development. Long-term architecture needs more than nominal assignment, however.

The important questions are who can actually protect a domain boundary, who can reject a problematic dependency even if that delays a promised feature, who can prioritize structural work, and who decides about a shared model used by ten teams. It also matters who carries the consequences of a decision for several years and who inherits the historical obligations of an area after a reorganization.

Ownership therefore separates into several dimensions: domain ownership, technical ownership, nominal accountability, real decision rights, and the ability to remain responsible for consequences over time. These dimensions do not have to sit with the same person or role. The problem starts when they drift so far apart that someone can be held responsible while nobody has the authority to make the necessary decisions.

Responsibility without sufficient decision-making power is not durable ownership.

This also explains why architecture rules alone do not create an organizational boundary. A rule may document that area A must not access area B directly. When an important deadline arrives, however, another question becomes decisive: who has the mandate to enforce that rule even when doing so costs money or time in the short term?

Current empirical research on technical-debt decisions therefore considers organizational authority and stakeholder interests alongside technical consequences. Wiese and Borowa additionally show from a management perspective how strongly technical-debt management is connected with budgets, deadlines, communication, and established decision processes. An architecture can have an owner on paper and still be effectively leaderless.

When domain ambiguity enters the code

Ownership also has a domain side. In the project described at the beginning, development repeatedly received requirements that only partially accounted for the existing system and its domain relationships. At the same time, there was not enough stable Product Ownership to translate those requirements consistently into a coherent domain model.

Again, this is an observation from one specific project. The generalization must not be that poor requirements inevitably create poor architecture. Complex domains contain real exceptions, business models change, regulation creates special cases, and products often have to support historical processes. Not every additional condition in the code is evidence of organizational failure.

The situation becomes harder when fundamental domain questions remain unresolved for long periods: Who owns a particular piece of state? Which process is authoritative? Which rule is binding? Is an exception genuinely required by the domain or merely historical? Which domain is allowed to change which state? If the organization cannot answer those questions, they do not disappear — development still has to build software.

Domain uncertainty can then be compensated for technically, for example through additional flags and parameters, multiple writers for the same state, duplicated rules, cross-domain shortcuts, shared state, or special paths whose responsibility nobody can explain clearly anymore.

Unclear domain ownership does not stay outside the code. Over time, it can become unclear technical ownership.

Requirements-engineering research has long shown that unclear requirements and communication problems are recurring challenges in real software projects. Research on the Product Owner role likewise describes it as a connection between business requirements, stakeholders, and implementation, while its effectiveness depends on the surrounding organizational context. This does not establish a simple causal path from “bad Product Owner” to “bad architecture.” It does explain why domain clarification and technical structure cannot be separated completely: a system can express clear domain boundaries only to a limited extent if the organization behind those boundaries does not itself have stable answers about responsibility.

Survival mode shortens the time horizon

In the project described above, executive leadership at times faced problems that were much more immediate than long-term architecture quality. Critical customers had to be served, budgets were tight, delivery obligations remained, and the economic future of the business unit itself was uncertain. From a technical perspective, it is easy to argue that long-term structural work is especially necessary in such a situation. From an organizational perspective, however, that work competes with problems whose consequences can arrive tomorrow.

Survival mode does not make long-term decisions unimportant. It can make them organizationally close to impossible.

This is not a criticism of leadership; it describes a time horizon. A cleaner technical boundary may generate its benefit only after several releases while an escalating customer needs an answer today. Reducing structural coupling may pay off over years while the budget problem exists in the current quarter. Under those conditions, the attractiveness of decisions changes.

This is where a feedback effect can emerge. Short-term economic pressure makes short-term technical choices more attractive. Some of those choices can make future changes more expensive. Higher change costs, in turn, increase delivery pressure, making long-term structural work even harder to prioritize. Technical-debt research explicitly treats such chains and cycles as useful ways to understand the phenomenon. From their interviews with IT managers, Wiese and Borowa model different levels of visibility as well as chains and cycles of causes and consequences; the international survey family mentioned earlier likewise shows how prominent time pressure is as a reported context for technical debt.

This does not mean economic pressure inevitably produces a Big Ball of Mud. It can, however, systematically shift the decision space toward the present.

Architecture needs a future in which the investment can pay off

That time horizon does not affect management decisions alone. In the project described above, people in development repeatedly made remarks that amounted to waiting for the business unit to be shut down. This is another project-specific observation; it supports neither a psychological diagnosis nor the claim that the Big Ball of Mud caused that attitude.

For architecture, however, it creates a straightforward economic question: why invest three weeks today in a technical boundary whose benefit is spread over the next three years if there is little expectation that the product will still exist three years from now?

Long-term architecture work is an investment. It creates cost in the present so that later changes can become cheaper, safer, or possible at all. Such an investment therefore requires at least a sufficiently long expectation horizon.

Architecture investment requires at least some expectation that the system has a future in which the investment can pay off.

That is not an appeal for optimism; it is a property of the investment logic. A team that sees its entire future in weeks will make different decisions from one that expects to work on the same codebase for another five years. When roles, budgets, and products are uncertain at the same time, this creates another mechanism that can favor locally rational short-term decisions.

When responsibility changes faster than the system

Not every personnel change causes knowledge loss. Well-documented systems, clear models, strong teams, and explicit decision processes can preserve substantial knowledge independently of individuals. But not everything can be documented completely: Why was an interface designed exactly this way? Which customer required a special case? Why may a particular state be changed only in one place? Which alternative was rejected at the time, and why?

Some of this information lives in tickets, documentation, and Architecture Decision Records; some of it lives in people. Research on turnover-induced knowledge loss shows that developer turnover can remove relevant technical and tacit knowledge from projects. Case studies of Chrome and an Avaya project, together with later research on how practitioners experience the problem, describe implementation knowledge and historical context as resources whose loss can make later development more difficult. This does not mean turnover causes a Big Ball of Mud. High personnel instability can, however, make it harder to preserve the reasoning needed to sustain long-term structures.

Developers, team leads, and development managers change, responsibilities are redrawn, but the codebase does not necessarily change with them. The result is an asymmetric process: historical decisions remain while knowledge about the reasons behind them is gradually replaced.

Who sustains a three-year architecture strategy if the responsible roles change several times during those three years?

The way leadership roles are filled should not be moralized either. In unstable organizations, roles are often taken on for pragmatic reasons: someone is available, a gap has to be filled quickly, existing relationships help, or the organization needs to remain operational. Architecturally, the relevant question is not whether such a decision was morally good or bad, but whether role, experience, legitimacy, and actual decision-making power fit together afterward.

“Shouldn’t the managing director be the one telling me this?”

In a later meeting with the CTO and a Lead Architect, the state of the system was presented together with its structural problems, a possible target state, and the need for broader change. The explicit goal of the meeting was to obtain organizational enablement for changes that had long exceeded what could be achieved through isolated refactorings inside one team. During the discussion, a question was raised roughly along these lines:

“Shouldn’t the managing director be the one telling me this?”

It would be easy to interpret that statement as disinterest in technology. That would be too simple. From a governance perspective, it contains a legitimate question: who has the mandate to escalate a problem of this scale? Who can derive priorities from it? Who can decide that several teams, budgets, and responsibilities will be affected?

That is precisely where the interesting mechanism appears. A technical diagnosis can be correct and still remain organizationally ineffective.

A technical problem does not become organizationally actionable simply because it has been diagnosed correctly. Someone also needs the legitimacy to act on that diagnosis.

Technical evidence and organizational authority are different things. A developer can prove that cycles exist, an architect can show that a dependency increases the change radius, and a team can demonstrate that a particular structure repeatedly makes changes more expensive. None of those roles automatically gains the right to change responsibilities, reallocate budgets, or obligate other units.

Architecture therefore reaches a point at which technical competence alone is no longer enough — not because technology becomes unimportant, but because changing technical boundaries can itself touch organizational boundaries.

When technical decoupling affects organizational control

In the same project, a proposed technical change was once described in a discussion, roughly, as a “hostile takeover.” Again, this is one specific experience, not a pattern that should be projected onto organizations in general. What made the phrase interesting was what was actually being changed: not corporate ownership, but technical boundaries, ownership, responsibilities, interfaces, and the question of which area would be allowed to make which decisions in the future.

From a technical perspective, decoupling can look remarkably mundane. A shared service is split, a domain responsibility receives a clearly defined interface, one global data model is replaced by several explicit models, or write access to a piece of state is reduced. Organizationally, however, more can change. A team may no longer be able to reach directly into another area, a role may lose informal control over a process, or decisions once made inside one unit may suddenly require coordination. A technical interface makes ownership explicit — and with it, potentially, who no longer owns something.

What looks like decoupling technically can feel like a loss of control organizationally.

This does not mean resistance to an architecture change is automatically a hidden power struggle. Technical proposals can be poor, existing responsibilities may have good reasons, and an apparently clean separation can make operations worse. Architecture does, however, have an organizational dimension whenever technical boundaries overlap with decision spaces.

Architecture changes more than dependencies. It can also change responsibilities, influence, and control.

Research on organizational change offers at least a useful interpretive frame here. In their theoretical and empirical work, Eilam and Shamir show that change can be perceived differently when it affects self-determination, continuity, or one’s professional role. This does not support remote diagnosis of particular individuals, nor does it prove that a particular architecture change was experienced as an identity threat. It does show why changes to responsibility may be evaluated on more than technical quality alone.

When the past suddenly becomes part of the discussion

A fundamental architecture diagnosis never describes only the present. If a system has grown for ten or fifteen years and an assessment concludes that its boundaries need to be rebuilt, that statement inevitably has a historical dimension. It can imply that earlier investments produced features, customers, or revenue but did not leave behind the structural foundation needed for the next stage of development.

At that point, more than code is involved. Earlier strategies, budgets, architecture decisions, and leadership concepts are viewed through a new lens. People may associate many years of professional work with those decisions, and organizations develop their own success stories about why particular projects were created and which decisions made them successful.

The important question is therefore not whether the people involved are “big enough” to admit a mistake. That would be psychologically and organizationally simplistic. A more useful question is:

Can an organization revise its previous success story without experiencing that revision as a personal accusation?

Research on organizational learning has long examined mechanisms through which organizations struggle to question their own assumptions and can stabilize defensive routines. Research on self-concept and organizational change adds that change is not processed only as a factual matter; it can also affect continuity and professional identity. These perspectives do not explain any specific reaction in a software project. They do help explain why a technically plausible reassessment of previous decisions can be organizationally much harder than analyzing the repository.

An architecture diagnosis can be technically correct and still sound like a verdict on the past. The larger the system and the longer its history, the more important that distinction becomes.

The Big Ball of Mud as a feedback system

Several mechanisms are visible by this point: time pressure, changing responsibilities, domain ambiguity, different decision horizons, knowledge loss, contractual boundaries, and missing decision rights. The important point is that these mechanisms do not have to occur independently; they can reinforce one another.

One possible cycle starts with economic pressure. That pressure makes locally attractive short-term solutions more likely, and some of those solutions increase technical coupling. Higher coupling later increases coordination needs and change radius, making changes more expensive and increasing delivery pressure again. Under that additional pressure, short-term solutions become attractive once more.

Another cycle can start with personnel instability. Frequent change removes part of the tacit knowledge around the system. Some areas become harder to understand and more dependent on the few remaining experts, changes take longer, onboarding becomes harder, and organizational strain can increase further. A third cycle can start with unclear domain ownership: unresolved domain decisions are compensated for technically through additional special cases and multiple responsibilities, making system boundaries less clear. That in turn makes it harder for future Product Owners and developers to reconstruct the domain model from the existing system.

These cycles are analytical models, not universal laws, and they will not appear identically in every system. They do, however, show why a Big Ball of Mud can be more than the sum of past poor code decisions.

Organizational conditions can repeatedly make exactly those local decisions attractive that continue structural boundary erosion.

In that sense, a Big Ball of Mud can reproduce itself organizationally — not because “the organization” deliberately creates poor architecture, but because the same conditions repeatedly reward similar local optimizations.

Structural erosion can reinforce itself when rising change costs create additional short-term pressure and make local shortcuts more attractive again.

What the research shows — and what it does not

Research does not provide a model that can reliably predict a Big Ball of Mud from a particular organizational structure. Software development is too context-dependent for that. Conway describes a relationship between communication structure and system design, the mirroring hypothesis examines empirical relationships between product and organizational architecture, and socio-technical congruence focuses on the coordination needs created by technical dependencies. Technical-debt research highlights, among other things, the importance of time pressure, budgets, stakeholders, management, and decision processes. Work on turnover examines the loss of development knowledge, while research on requirements and Product Ownership shows how strongly domain clarification depends on communication and organizational context.

None of these research traditions says that management creates poor architecture. Nor do they justify the opposite claim that developers are merely victims of their organization. Technical decisions remain technical decisions; developers, architects, and teams have agency and responsibility.

The empirical literature does, however, suggest that the context of those decisions matters. A software organization helps determine how expensive coordination is, distributes decision rights, defines budget and planning horizons, assigns responsibilities, decides which stakeholders are involved, and creates the conditions under which long-term and short-term goals are weighed against each other. It preserves knowledge — or loses it.

The organization does not determine every line of code. But it changes the space in which that line of code is written.

Why the code could still be “the smallest problem”

This brings the Principal Architect’s statement from the beginning into a different light. The code was anything but “small”: the thousands of files, cyclic dependencies, global state, missing boundaries, and hard-to-understand impact chains remained real technical problems. Yet there were at least technical operations available for them. Code can be analyzed, dependencies visualized, tests built, responsibilities reshaped, modules extracted, and state decoupled. Even a very poor technical state still offers technical entry points for change.

That kind of change requires more than a correct target architecture, however. It needs enough continuity to sustain one direction over several years, enough domain clarity to define new technical boundaries meaningfully, and enough decision-making power to handle conflicts between short-term interests and long-term structural goals. Once technical boundaries affect existing responsibilities, it also needs organizational legitimacy and a time horizon in which the investment in structure can pay off.

A technically sound remediation strategy can therefore still fail if the organization cannot sustain it long enough. That shifts the diagnosis: the Big Ball of Mud is technically visible, but its history reaches through many layers of the organization.

Research literature

• Besker, Terese; Martini, Antonio; Bosch, Jan (2022): The use of incentives to promote technical debt management. Information and Software Technology, 142, 106740. DOI: 10.1016/j.infsof.2021.106740.
• Cataldo, Marcelo; Herbsleb, James D.; Carley, Kathleen M. (2008): Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity. ESEM 2008. DOI: 10.1145/1414004.1414008.
• Conway, Melvin E. (1968): How Do Committees Invent? Datamation.
• Eilam, Galit; Shamir, Boas (2005): Organizational Change and Self-Concept Threats: A Theoretical Perspective and a Case Study. The Journal of Applied Behavioral Science, 41(4), 399–421. DOI: 10.1177/0021886305280865.
• Klotins, Eriks; Unterkalmsteiner, Michael; Gorschek, Tony (2019): Software engineering in start-up companies: An analysis of 88 experience reports. Empirical Software Engineering, 24(1), 68–102.
• MacCormack, Alan; Baldwin, Carliss Y.; Rusnak, John (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.
• Nielsen, Mille Edith; Madsen, Christian Østergaard (2022): Stakeholder influence on technical debt management in the public sector: An embedded case study. Government Information Quarterly, 39(3), 101706. DOI: 10.1016/j.giq.2022.101706.
• Ramač, Robert et al. (2022): Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry. Journal of Systems and Software, 184, 111114. DOI: 10.1016/j.jss.2021.111114.
• Rigby, Peter C.; Zhu, Yue Cai; Donadelli, Samuel M.; Mockus, Audris (2016): Quantifying and mitigating turnover-induced knowledge loss: Case studies of Chrome and a project at Avaya. Proceedings of ICSE 2016, 1006–1016. DOI: 10.1145/2884781.2884851.
• Robillard, Martin P. (2021): Turnover-induced knowledge loss in practice. Proceedings of ESEC/FSE 2021, 1292–1302. DOI: 10.1145/3468264.3473923.
• Wiese, Marion; Borowa, Klara (2023): IT managers’ perspective on Technical Debt Management. Journal of Systems and Software, 202, 111700. DOI: 10.1016/j.jss.2023.111700.

Conclusion

When the Principal Architect summarized the technical state with the phrase “the code is the smallest problem,” the point was not that the architecture was harmless. It was severely eroded. The code did, however, have one property that many of the other problems did not: it could be analyzed and changed with technical means. The harder question was which organization could sustain that change over a long period of time.

Dependencies and global state are implemented by developers, so technical responsibility remains with the people making technical decisions. The conditions under which those decisions are made extend further. Requirements shape them just as economic pressure does; contracts define boundaries, team structures shape coordination paths, responsibilities change, and knowledge is lost or has to be rebuilt. Leadership sets time horizons and priorities, while decision rights determine who can protect a technical boundary even when doing so is inconvenient in the short term.

A Big Ball of Mud is therefore not either a technical or an organizational phenomenon. The two levels interact. Local decisions become durable in code while the organization continues to change. New teams inherit the technical decisions of their predecessors and make further decisions under new constraints. Over time, a codebase can accumulate the traces of many requirements, budgets, projects, leadership structures, team boundaries, and contracts.

The Big Ball of Mud is visible in the repository. Its causes do not live there alone.

If technical, domain, organizational, and economic forces all contributed to the conditions under which this state emerged, sustainable change will also require more than a purely technical perspective. How those forces can be brought together is a different question.

Architecture lives in code. But the forces that shape it reach far beyond the codebase.