The Economics of a Big Ball of Mud

A Big Ball of Mud can be economically rational.

That may sound like a contradiction in a series that has spent so much time on lost boundaries, expanding change radii, implicit dependencies, and the organizational consequences of technically eroded systems. From an economic perspective, however, this counterpoint matters. Architecture has no economic value merely because it is clean. Its value comes from how well it supports current and future requirements at an acceptable cost.

Imagine a product that has been in operation for fifteen years. Only a small number of customers still use it. Hardly any new features are planned, the infrastructure is stable, regulatory changes are rare, and a replacement has already been scheduled for a few years from now. The code may be heavily eroded, its internal structure difficult to understand, and changes unpleasant to make. Even so, launching a fundamental modernization effort could be irrational.

Refactoring, migration, replatforming, and rewrites are not free either. They consume development capacity, introduce transition risk, can delay product work, and often require data migration, training, and parallel operation. Technical improvement itself has opportunity costs because the same people cannot use that time for something else.

Not every piece of technical debt has to be repaid.

The economically correct response to a Big Ball of Mud is therefore not automatically to remediate it. The more interesting question is under which conditions its current state remains tolerable—and when poor changeability starts to undermine the company’s ability to act economically.

The economics of a Big Ball of Mud are not determined by how ugly its code is, but by the price the company pays for future change, uncertainty, and responsiveness.

Two products, the same technical quality, completely different economics

Consider two products with similarly problematic internal structures.

Product A is near the end of its life cycle. It is still operated and maintained, but hardly developed further. The number of users is declining, a successor already exists, and the remaining maintenance team only implements necessary changes.

Product B, by contrast, is a strategic core product. New features are released continuously, further integrations are planned, several teams work on it, and the product is expected to remain in the market for many years.

Technically, the two systems can be equally poorly structured. Economically, they are in entirely different situations.

For Product A, a comprehensive remediation effort could cost more than all realistically expected future changes combined. The company would be investing in changeability it will probably hardly use.

For Product B, the same poor changeability becomes relevant again with every new feature. What is merely an unpleasant technical property today becomes a recurring part of production cost over the coming years.

The technical state alone does not determine whether a Big Ball of Mud is economically problematic. What matters is the relationship between that state and the product’s future need for change.

The technical state alone does not determine the economics. What matters is how much future change the company expects from the system.

The greater a product’s future need for change, the greater the economic value of a structure that keeps changes local, controllable, and sufficiently predictable. This is neither a formula nor a universal threshold. It is a relationship between the cost of technical change and the amount of change the product is still expected to undergo.

Expected change demand is what matters

A Big Ball of Mud is not primarily expensive because it is running today. It becomes economically relevant when it has to be changed.

For any business change, some of the work necessarily belongs to the change itself: a new rule is implemented, a user interface is adapted, a process is extended, or an interface is added. This work would also exist in a well-structured system.

But additional work may be required that does not follow from the business requirement itself. Developers may first need to understand historical structures, discover implicit dependencies, or determine which distant parts of the system could be affected. Additional regression testing becomes necessary, workarounds have to be considered, side effects repaired, and experienced people involved for validation.

As a conceptual distinction, we can write:

Change cost = business work + structurally induced additional work

This is explicitly not a precise cost model. It merely separates two different sources of effort. The first comes from the desired product behavior. The second comes from having to change that behavior inside an existing technical system.

Technical-debt research provides empirical evidence that such additional work can be economically relevant. Besker, Martini, and Bosch examined how much development time participants reported as being consumed by technical debt in a longitudinal study involving 43 developers, supplemented by interviews. In the 2019 replication and extension study, the reported average was about 23 percent; additional testing was among the most frequently mentioned activities.

That number requires an important qualification: technical debt is not the same thing as a Big Ball of Mud. The study therefore does not show that a Big Ball of Mud “costs 23 percent productivity.” It demonstrates something more general and still economically relevant: technical liabilities can shift a substantial share of working time into activities that are required in addition to the actual business change.

That shift is precisely what makes technical erosion economically interesting.

Output decline: not less work, but less business output

From the outside, an eroding system can initially look like a staffing problem.

A team may once have delivered several major requirements per quarter. Years later, the same organization visibly delivers less. It is easy to conclude that the developers have become slower, the processes are inefficient, or the team needs more performance pressure.

That can be true, but it does not have to be the cause. A growing share of the same available capacity may now be spent on system comprehension, defect correction, regression, validation, coordination, workarounds, incident work, or repairing unintended side effects. People are not necessarily working less; a larger share of their work is simply required to compensate for the changeability of the existing system.

The study by Besker, Martini, and Bosch is also useful for this distinction: time attributed to technical debt did not simply disappear. It was consumed by additional development activities.

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

Economically, that distinction matters. The company keeps financing the same development capacity, but a growing share of it produces no new business functionality and instead compensates for structural properties of the existing system.

A scientific boundary

At this point, an explicit boundary is necessary, and it applies throughout this article.

There is empirical research on technical debt, maintainability, coordination, software effort estimation, legacy onboarding, software evolution, and security patching. These research areas examine mechanisms that can also be relevant to a Big Ball of Mud.

They do not jointly measure a universal category called “Big Ball of Mud,” nor do they provide a reliable number for how much more expensive, slower, or less predictable such a system generally is.

When this article argues, for example, that an unknown change radius can create additional estimation uncertainty, that is therefore an architectural hypothesis: if relevant dependencies are unknown before a change starts, information is missing at the time of estimation. The general difficulty of software effort estimation is empirically studied. The Big-Ball-of-Mud-specific transfer is an inference from the mechanism described here, not a directly measured percentage.

The same distinction applies later to security patching, onboarding, and opportunity costs. It matters because false precision makes an economic argument weaker, not stronger.

From change radius to business risk

The term change radius has already been introduced technically earlier in this series. For the economic perspective, the important question is not how it emerges in the code, but what happens when it grows or cannot be determined reliably before a change begins.

The farther a change actually reaches, the more code may need to be understood. More components may have to be tested, additional teams may become involved, and more organizational coordination may be required. At the same time, the likelihood increases that what began as a local effort will reveal new dependencies during implementation.

That changes the perspective: what begins as a technical question for a developer—Which parts of the system do I have to touch for this change?—can become an economic question for a stakeholder—When will this change be finished, and how reliable is that statement?

A developer’s change radius can become a stakeholder’s business risk.

Coordination costs: effort is not lead time

This becomes particularly visible when technical dependencies create organizational dependencies. A change may require several teams, different owners, shared testing, architectural decisions, or coordinated releases. The result is not only more working hours, but also handoffs and waiting time.

Research on socio-technical congruence studies precisely the relationship between technical dependencies and the coordination needs of software development organizations. In an empirical study, Cataldo, Herbsleb, and Carley found that when developers’ actual coordination patterns aligned with the coordination requirements created by the work, modification requests were resolved significantly faster.

That does not imply that every Big Ball of Mud inevitably causes a specific number of additional meetings. The research does, however, support the underlying mechanism: technical dependencies create coordination requirements.

This is why effort and lead time must be considered separately.

A feature may contain only a few days of actual implementation work and still require several weeks before delivery. Team A may first need to change an interface, Team B has to respond to it, a shared test environment must then become available, and finally the change waits for a coordinated release.

Those additional weeks do not appear in any line of source code. Economically, they are still real.

Technical unpredictability can propagate through schedules and dependencies into the company’s business planning.

Not only higher cost, but higher variance

The economic difficulty of a Big Ball of Mud may not even lie primarily in every change being expensive. A more serious issue can be that, before work begins, it is difficult to tell which change will become expensive.

Consider two purely illustrative systems. In System A, comparable changes reliably require between 20 and 25 person-days. In System B, one change takes five days, another 70 or 80—and at the start it is difficult to determine which case lies ahead.

These numbers are not empirical findings. The thought experiment illustrates a property that disappears in averages. Even if both systems had similar mean effort over time, System B would have an additional economic problem: greater uncertainty.

Predictability has economic value.

Companies need to allocate budgets, plan releases, prepare marketing, coordinate customer migrations, meet contractual obligations, staff teams, and synchronize other projects around common dates. Thirty days of known effort is economically different from effort that could fall anywhere between five and eighty days—even if the long-term average were identical.

Software effort estimation is difficult even without a Big Ball of Mud. Jørgensen and Shepperd identified 304 papers on software cost estimation in their systematic review and emphasized, among other things, the importance of study and dataset context. Jørgensen’s reviews of expert estimation likewise show how strongly available contextual information and the organizational situation can affect estimation quality.

This research does not establish that Big Balls of Mud have a particular higher estimation variance. The more cautious transfer is this: if the true change radius of a requirement becomes visible only during implementation, potentially relevant information is missing at estimation time. That adds another source of technical uncertainty to an estimation problem that is already difficult.

Stakeholders pay for technical unpredictability

That uncertainty does not necessarily remain inside the development organization. A promised delivery date may be tied to a customer project. Other systems may depend on a shared release version. Marketing activities, training, or migrations may have been scheduled around the same date. Contracts can contain deadlines whose violation has commercial consequences.

This does not imply:

A Big Ball of Mud causes contractual penalties.

The economic chain is conditional:

technical uncertainty → schedule uncertainty → planning risk → potentially contractual, revenue, or reputational risk

The lower the technical predictability, the greater the risk can become that uncertainty in engineering propagates into obligations outside the development organization.

The important point is not that every delay immediately costs money. It is enough that the organization has to make decisions under greater uncertainty.

A company does not pay for poor changeability only with additional development effort. It may also pay with lost predictability.

Opportunity costs: what does not get built?

The directly visible additional cost of a change is comparatively easy to understand.

Take another thought experiment: in a well-understood system with local changeability, a requirement might have needed 15 person-days. In the current system it takes 40 because of additional analysis, regression work, and side effects.

The visible difference is 25 person-days. Economically, however, the more interesting question is:

What could the team have built during those 25 person-days instead?

That is where opportunity cost enters the picture. The scarce resource is not only money but development capacity. Every hour spent on structurally induced additional work is unavailable for another improvement, another customer need, or another form of risk reduction.

A second effect is even less visible: a requirement is analyzed and judged technically too expensive. Product management decides:

It is not worth it.

The requirement is never implemented. In a conventional technical-debt cost calculation, it may never appear at all. There was no additional implementation effort, no failed sprint, and no visible rework. Yet the technical structure still influenced an economic decision.

A Big Ball of Mud does not only make changes more expensive. It can change which changes still appear economically viable.

At that point architecture begins to shape product strategy. The technical state narrows the economic solution space. Ideas may be rejected not because they lack market value, but because implementing them in the existing system appears too expensive or too risky.

Cost of delay and time to market

Opportunity costs capture what cannot be done simultaneously because capacity is tied up. Delay adds another dimension: the expected value of a change arrives later.

Research on product-development economics therefore does not treat time to market as an isolated engineering speed metric, but as a trade-off among development duration, product performance, market windows, competition, and expected economic benefit. Cohen, Eliashberg, and Ho modeled this trade-off for new product development in 1996 and showed, in particular, that maximizing speed is not universally economically optimal; the best decision depends on market and product context.

That distinction maps well to architecture. A feature whose delivery is delayed for technical reasons is not automatically an economic loss. Its market timing may be uncritical, or additional development time may substantially improve its value.

But if expected value is time-sensitive, delay can have a double effect: the company invests in implementation for longer and realizes the expected benefit later.

For a competitive product, a limited market window, or a contractually relevant function, that effect can matter more than the additional developer hours themselves.

Time to market is therefore not an abstract management metric. It can become an economic consequence of technical changeability.

Architecture as option value

So far, changeability has mainly been discussed as a way to reduce effort and delay. Its strategic value can go further.

Companies do not know today every decision they will have to make in three or five years. A new business model may emerge. Regulation may change the handling of data. A platform may be discontinued. A new sales channel may appear. The product may expand into another market, or a previously central external API may have to be replaced.

In such situations, flexibility has an option-like character. Sullivan, Griswold, Cai, and Hallen applied real-options thinking to modular software structures and used it to examine the economic value of modularity and information hiding. Their approach does not imply that every architectural decision can be priced exactly like a traded financial option. Rather, it provides an economic model for why the ability to defer decisions until better information is available can have value.

The strategic idea is simple:

We do not need to know today which of these changes will happen. It is enough if we can still react when they do.

Good architecture does not only buy speed. It buys the company freedom to decide.

A heavily hardened system can gradually reduce that freedom. A technically possible change can become so costly, slow, or risky that it is no longer an economically realistic option.

That does not mean that maximum flexibility is always optimal. Flexibility itself costs development effort. Carrière, Kazman, and Ozkaya likewise argue for evaluating architectural decisions through explicit cost-benefit reasoning in their business context.

The economic value is therefore not in anticipating every conceivable future. It is in retaining sufficient room to act under relevant uncertainty.

But “we do not need any more features” is not enough

This brings us back to the counterpoint at the beginning.

If a product is barely being developed further, the expected value of high changeability decreases. That is precisely why accepting a technically poor state can be economically rational.

But the calculation contains an uncertainty:

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

Not every future change is initiated by product management. Conceptually, two sources can be distinguished.

Endogenous changes

Endogenous changes are largely initiated by decisions inside the company. Examples include:

• new features,
• changes to the user experience,
• new business models,
• refactorings,
• additional integrations,
• strategic product changes.

An organization has at least some discretion over many of these changes. If their cost is too high, they can be postponed, simplified, or abandoned entirely.

Exogenous changes

Exogenous changes, by contrast, originate in the system’s environment:

• newly discovered security vulnerabilities,
• legal or regulatory changes,
• new compliance requirements,
• changes to external interfaces,
• platform or operating-system changes,
• changes in browsers or cloud platforms,
• discontinued libraries, runtimes, or protocols.

The company has much less control over when such events occur.

The future need to change a software system is not determined exclusively by product management.

Future change demand is not determined exclusively by product management. Some changes originate outside the company’s own roadmap.

Software evolution: the environment keeps moving

The idea that long-lived software has to react to a changing environment is not new.

Meir M. Lehman studied software evolution from the 1970s onward. His work distinguishes, in particular, so-called E-type systems: systems embedded in real processes and environments whose usefulness therefore remains tied to that environment. The well-known Laws of Software Evolution include Continuing Change and Increasing Complexity.

These “laws” should not be read as immutable laws of nature for every modern software system. They emerged from empirical observations of particular long-lived systems and were later refined and debated. Lehman revisited them in 1996 in the context of continuing research.

For the economic argument, however, a robust core idea remains: a system that interacts with a real organizational, technical, or social environment can lose relevance if that environment changes while the system does not adapt.

A product may be functionally complete. Its environment is not therefore complete as well.

A frozen feature backlog does not freeze the environment in which the software operates.

Security: change under externally imposed time pressure

Security vulnerabilities are a particularly clear example of exogenous change.

An organization cannot reliably choose when a new vulnerability is discovered, when information about it becomes public, or how urgently it must respond. Depending on the situation, a change may be planned over time—or it may have to be made quickly.

Good architecture does not prevent security vulnerabilities. A well-structured system can be vulnerable too. What architecture can influence is the set of conditions under which a necessary change can be made.

Empirical security research shows that patch distribution in complex technical ecosystems can be delayed substantially. Zhang, Zhang, Qian, and Lau examined patch propagation in the Android kernel ecosystem in 2021. In the decentralized and fragmented supply chain they studied, patches passed through several technical and organizational layers; in some cases, months or even years separated a publicly available patch from its application on end devices.

This study does not examine a Big Ball of Mud. Its finding is different: security remediation can be delayed considerably by technical and organizational dependencies. The transfer to a Big Ball of Mud is therefore again an architectural hypothesis:

A system with high coupling and poorly predictable change radii can become an economic risk precisely when a change cannot be postponed.

For an optional feature, a company can decide that implementation is too expensive. For a critical security fix, that freedom may not exist.

At that point, poor changeability becomes a responsiveness risk.

Legal and regulatory change

Security is not the only external driver.

Legal or regulatory requirements may have fixed deadlines. They can require new forms of data processing, change business processes, demand additional evidence, or affect interfaces. Changes to industry standards or mandatory platforms can likewise force technical adaptation.

In such a situation, the economic question is no longer only:

Is this change worth it?

It may become:

Can we implement this change reliably within the time available?

That changes the value of changeability fundamentally.

Architecture does not determine whether a company will be hit by unexpected change. It helps determine how well the company can respond to it.

This is why “this product no longer gets features” is not, by itself, a sufficient economic argument for leaving its technical state untouched. The company must also consider what external changes the product may face during the remainder of its life.

Cost, predictability, and responsiveness

Three distinct economic dimensions of changeability can now be separated.

1. Change cost

How much work is required to implement a desired or necessary change reliably?

This dimension includes the additional analysis, testing, coordination, and rework that a hard-to-change system can create.

2. Predictability

How reliably can effort and duration be estimated before a change begins?

This matters for budgets, schedules, dependencies, and commercial commitments. An expensive change can still be predictable. A change whose true scope varies sharply and only becomes visible during implementation can be much harder to manage organizationally.

3. Responsiveness

How quickly and controllably can the organization act when a change cannot simply be postponed?

This is where security, regulation, platform changes, and other external drivers become relevant.

These three dimensions should not be collapsed into a deceptively precise metric. They represent different forms of economic exposure.

The economic value of changeability is not only that it makes changes cheaper. It also keeps cost, duration, and risk within a manageable corridor.

The economic cost of a change can extend far beyond the business implementation itself.

Hiring is more than recruiting

Software changes, and so do the people who change it.

Finding new developers already consumes time and money. From the perspective of a long-lived system, however, recruiting is only the beginning. A new employee has to understand the domain, master the development environment, learn technical and organizational rules, and eventually acquire enough system knowledge to make changes safely.

A Big Ball of Mud can add a particular difficulty: a substantial part of the effective architecture may not be documented explicitly or locally inferable from the code. Knowledge about which areas are connected, which paths are dangerous, and why apparently strange solutions exist may instead live with experienced people.

Empirical research on legacy onboarding shows that acquiring this knowledge can be a significant challenge. Britto, Cruzes, Šmite, and Šāblis studied three globally distributed legacy projects. They describe learning legacy code as a particular difficulty, amplified in their cases by project scale and distance from the original sources of knowledge.

That does not mean onboarding in a Big Ball of Mud has been empirically shown to take a fixed percentage longer.

The cautious transfer is:

Research on legacy projects shows that acquiring historical system knowledge can be a major onboarding challenge. In a Big Ball of Mud, this mechanism is likely to matter especially when a large part of the effective architecture is known only implicitly.

Poor structural intelligibility therefore acquires a direct staffing-cost dimension.

The hidden cost of ramp-up

Onboarding does not only consume the new employee’s time.

A developer learning an unfamiliar system needs support from people who already understand it. They answer questions, explain historical decisions, pair on changes, review work, and help prevent mistakes in areas whose risks are difficult to infer from the code alone.

Britto and colleagues describe coaching and mentoring by experienced developers among the onboarding practices in the legacy projects they studied. Economically, this creates an often underestimated double effect.

While the new employee is learning, the organization pays for that learning time. At the same time, capacity is consumed from an experienced person—and in a hard-to-understand system, that person may already be a scarce resource.

Ramp-up does not only cost the productivity of the newcomer. It also consumes the productivity of the people who hold the implicit knowledge.

The people a company needs in order to scale a team can therefore initially place additional demand on the very people who are already bottlenecks.

A system cannot be scaled organizationally by simply adding heads. New capacity must first be trained by existing capacity.

Turnover costs and lost knowledge

The previous article in this series looked at what hard-to-change systems can do to people and organizations. For the economic perspective, the opposite direction is sufficient here: what happens to the system when people leave?

A new developer who leaves after a relatively short period takes part of the recent investment with them. Recruiting, onboarding, mentoring, and accumulated system knowledge must be rebuilt for a successor.

With long-tenured employees, the problem can be reversed. When someone leaves who understands historical relationships, information may disappear that was never fully represented in documentation, tests, or structure.

In 2021, Robillard conducted qualitative interviews with 27 professional developers and managers from three companies and derived a framework for characterizing turnover-induced knowledge loss. The work is not a Big-Ball-of-Mud study, but it shows that developer turnover can remove relevant technical knowledge from teams.

The more strongly a system depends on implicit historical knowledge, the more plausible this mechanism becomes in its economic analysis.

New people can be expensive to ramp up. Experienced people can be expensive to lose.

A Big Ball of Mud can intensify both sides when safe change depends heavily on knowledge held by only a few individuals.

The asymmetric business-case problem

Why is it still often so difficult to formulate an economic business case for structural improvement?

One reason is a fundamental asymmetry. The cost of remediation is visible: an analysis may conclude that a migration would occupy several teams for months. Refactorings consume concrete capacity. New infrastructure has to be built, data migrated, and existing behavior protected. Those costs appear in the budget. The benefit of better changeability, by contrast, often consists of future additional work that no longer has to be done.

A developer does not spend three days tracing a dependency. A second team does not have to become involved. An additional regression test is unnecessary. A feature does not wait another week. A newcomer understands a boundary directly from the structure rather than having it explained by an expert.

None of these events appears in a success report precisely because they did not happen.

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

That creates a difficult business case.

Suppose, purely illustratively, that remediation would cost 500 person-days. That number is concrete. The counterargument may be that the investment would prevent an unknown amount of analysis, coordination, regression, incident, and delay cost over the next five years.

The first number is visible and immediate. The second is distributed, probabilistic, and partly counterfactual: it requires estimating costs that would otherwise have occurred.

That is precisely why the opposite form of architecture dogma must also be avoided. Invisible benefit is not automatically large benefit. An expensive modernization can simply fail to have a positive business case.

The economic task is to compare both sides under uncertainty, not to turn technical cleanliness into a moral objective.

Tail risk: rare, but expensive

This brings us to the hardest part of the decision for products with low expected change demand.

It may genuinely be very likely that only a few changes will be necessary over the next three years. In that case, leaving a hard-to-change system largely untouched can be economically sensible.

One question still remains:

What happens if a rare but mandatory change occurs?

A critical vulnerability is disclosed. A statutory deadline requires an adaptation. A central platform is discontinued earlier than expected. A previously stable external service changes its interface.

For these cases, average expected maintenance cost is not the only relevant variable. The probability of occurrence, potential damage, available response time, and technical ability to act safely within that time all matter.

No complex financial risk model is required to preserve one important distinction:

“We expect hardly any changes” is a forecast, not a guarantee.

A company may consciously choose to carry that risk. It should simply not confuse “little planned product development” with “no necessary future change.”

No architecture religion

This closes the circle back to the counterpoint at the start.

An old Big Ball of Mud can be economically rational to tolerate. This is particularly true when its replacement is reliably planned, the remaining lifetime is short, few changes are expected, and relevant external risks remain manageable.

In that situation, remediation may consume more money, time, and risk than it could ever recover during the product’s remaining life.

The exact same technical structure can be economically problematic in a strategic core product. If new features are delivered continuously, many integrations change, regulatory responsiveness matters, security fixes must be applied quickly, the engineering organization is growing, or the product is expected to operate for many more years, changeability itself becomes a production factor.

A Big Ball of Mud can be economically rational to tolerate in a product near the end of its life cycle. It becomes problematic when the company simultaneously expects continuous change from the same structure.

The decisive question is therefore not whether the code conforms to modern architectural preferences.

It is:

What price does the company pay to keep changing this system?

That price can take the form of additional development hours. But it can also appear as coordination effort, longer lead time, lower estimability, delayed value, difficult onboarding, constrained expert capacity, or lost strategic options.

And the price can change.

A system that made economic sense in maintenance mode yesterday can require a completely different assessment tomorrow if product strategy, regulation, the security environment, or its expected remaining lifetime changes.

The economics of a Big Ball of Mud are therefore not a static property of the code.

They are a relationship between the technical state and the changes an organization needs the system to absorb today and in the future.

Conclusion

A Big Ball of Mud can remain economically viable for a long time.

If a product is stable, rarely changed, and has a limited remaining lifetime, accepting technical erosion can be entirely rational. Comprehensive remediation carries its own costs, risks, and opportunity costs. Not every piece of technical debt has to be repaid.

As the need for change grows, however, the calculation changes.

An increasing share of development capacity can then flow into work that produces no new business value but is necessary simply to modify the existing system: comprehension, regression, coordination, workarounds, rework, and validation. Technical dependencies can increase lead time, unknown change radii can add uncertainty to an already difficult estimation problem, and high change costs can influence product decisions before any code is written.

Costs also arise outside individual changes. New developers must acquire historical system knowledge and consume experienced colleagues’ time while doing so. When a knowledge holder leaves, difficult-to-replace knowledge can disappear. And when development capacity is absorbed by structurally induced additional work, the company does not merely lose hours—it loses the features, improvements, and risk-reduction work that could have been done instead.

It would still be wrong to turn that into a universal modernization mandate.

Continuing to operate a Big Ball of Mud is an economic bet on the future. The bet becomes more plausible when expected change demand remains low, remaining lifetime is limited, onboarding and knowledge loss remain manageable, and rare mandatory changes can still be implemented safely within the existing structure.

Because some of the actual need for change lies outside the company’s roadmap. Security vulnerabilities, regulatory requirements, platform changes, and external interfaces can require a response even when nobody has planned another feature.

The economic value of architecture is not only that it makes changes cheaper. It also keeps their cost, duration, and risk within a manageable corridor.

A frozen feature backlog does not freeze the environment in which the software operates.

A company therefore does not pay for a Big Ball of Mud only with development time. In the worst case, it pays with its ability to respond to change when that change can no longer be postponed.

References

• Besker, T., Martini, A. & Bosch, J. (2019). Software Developer Productivity Loss Due to Technical Debt – A replication and extension study examining developers’ development work. Journal of Systems and Software, 156, 41–61. DOI: 10.1016/j.jss.2019.06.004.
• Britto, R., Cruzes, D. S., Šmite, D. & Šāblis, A. (2018). Onboarding software developers and teams in three globally distributed legacy projects: A multi-case study. Journal of Software: Evolution and Process, 30(4), e1921. DOI: 10.1002/smr.1921.
• Carrière, S. J., Kazman, R. & Ozkaya, I. (2010). A cost-benefit framework for making architectural decisions in a business context. Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, Volume 2, 149–157. DOI: 10.1145/1810295.1810317.
• Cataldo, M., Herbsleb, J. D. & Carley, K. M. (2008). Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity. Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, 2–11. DOI: 10.1145/1414004.1414008.
• Cohen, M. A., Eliashberg, J. & Ho, T.-H. (1996). New Product Development: The Performance and Time-to-Market Tradeoff. Management Science, 42(2), 173–186. DOI: 10.1287/mnsc.42.2.173.
• Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1–2), 37–60. DOI: 10.1016/S0164-1212(02)00156-5.
• Jørgensen, M. (2007). Forecasting of software development work effort: Evidence on expert judgement and formal models. International Journal of Forecasting, 23(3), 449–462. DOI: 10.1016/j.ijforecast.2007.05.008.
• Jørgensen, M. & Shepperd, M. J. (2007). A Systematic Review of Software Development Cost Estimation Studies. IEEE Transactions on Software Engineering, 33(1), 33–53. DOI: 10.1109/TSE.2007.3.
• Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076. DOI: 10.1109/PROC.1980.11805.
• Lehman, M. M. (1996). Laws of Software Evolution Revisited. In: Montangero, C. (Ed.), Software Process Technology, Lecture Notes in Computer Science, Vol. 1149, 108–124. Springer. DOI: 10.1007/BFb0017737.
• Robillard, M. P. (2021). Turnover-Induced Knowledge Loss in Practice. Proceedings of the 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 1292–1302. DOI: 10.1145/3468264.3473923.
• Sullivan, K. J., Griswold, W. G., Cai, Y. & Hallen, B. (2001). The Structure and Value of Modularity in Software Design. Proceedings of the 8th European Software Engineering Conference held jointly with the 9th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 99–108. DOI: 10.1145/503209.503224.
• Zhang, Z., Zhang, H., Qian, Z. & Lau, B. (2021). An Investigation of the Android Kernel Patch Ecosystem. 30th USENIX Security Symposium (USENIX Security 21), 3649–3666. USENIX Association.