Nobody Built It

Nobody starts a software project with the goal of building a system whose consequences will be almost impossible to predict ten years later. Unclear responsibilities, far-reaching dependencies, or areas understood by only a handful of long-time developers never appear in an architecture document as the intended end state. At the beginning, there is usually something much more reasonable: a problem, an idea, a customer, a market opportunity, a deadline, or a technically demanding proof of concept. People are trying to make something work.

The previous article looked at what a Big Ball of Mud actually is: not a synonym for a monolith, legacy software, or Technical Debt, but a structural condition in which the intended or visible architecture explains less and less reliably how the system is actually organized. That leads almost inevitably to the next question: How can a system end up in that state even though nobody consciously sets out to create it?

The easy answer would be a story about bad developers, short-sighted management, or missing architectural expertise. The more interesting answer is harder:

A Big Ball of Mud is rarely built deliberately. It can emerge over years from many decisions that were understandable, sensible, or even successful in their local context.

A small editorial apology up front: this article is longer than the previous entries in the series. That is not because the answer needs to be made artificially complicated, but because looking for a single cause quickly becomes misleading. There is no single path into a Big Ball of Mud. One system may erode gradually as locally reasonable decisions accumulate over the years. Another may already be structurally compromised when a new team inherits it under entirely different contractual and organizational conditions. Yet another may grow out of a successful prototype without the transition from experiment to long-lived product ever being reflected in its structure.

These paths differ significantly. What they share is primarily one question: Who owns responsibility for the structure of the system over time — and can that responsibility actually have an effect?

Sometimes the Story Begins with Success

Brian Foote and Joseph Yoder do not begin their description of the Big Ball of Mud by accident with patterns such as Throwaway Code and the Permanent Prototype. A prototype pursues a different goal from a long-lived product. It is supposed to answer a question: Does the idea work? Is the algorithm feasible? Can the technical problem be solved at all? Can the concept be demonstrated?

For that purpose, a prototype may make assumptions that would be inappropriate for a production system. It may encode knowledge directly in the code, skip abstractions, or use structures whose long-term maintainability is initially secondary. That is not a mistake; it is precisely the purpose of exploration.

Things become interesting when the prototype succeeds. The demonstration convinces people, a customer becomes interested, someone recognizes a market opportunity, and suddenly that exact code has economic value. Knowledge, development time, and working solutions are already embedded in it. Foote and Yoder describe exactly this risk: throwaway code is not thrown away because the alternative initially means rebuilding something that already works. They do not claim that prototypes inevitably create bad products. Exploration may be necessary before the right structure of a domain can even be understood. The problem begins when the transition from experiment to long-lived system is not followed by a corresponding structural transition.

The success of a proof of concept can be exactly the reason it is never thrown away. Success preserves early decisions.

I have experienced a variation of this story myself. It began with an exceptionally demanding scientific and technical idea. A highly qualified scientist had solved a difficult problem and demonstrated its technical feasibility; the scientific achievement behind it was impressive. An entrepreneur recognized the economic potential of the solution — and that judgment also turned out to be correct. The proof of concept became a product.

At what point should someone have said: This is where the Big Ball of Mud begins? Certainly not there.

Locally Good Decisions

Once a product becomes successful, the situation changes. A customer is waiting for a feature, an incident needs to be resolved, a contract has a deadline, or a new technical concept is not yet sufficiently understood within the team. Perhaps the existing structure would first have to be reworked for a clean solution, while a pragmatic workaround could be completed today. Under those conditions, the workaround may be the reasonable decision.

Software development cannot be optimized exclusively for a hypothetical future. Companies have to ship products, users need working systems, and a structurally perfect design that reaches the market too late can be the worse decision economically. Research on Architectural Technical Debt describes the same ambiguity: architectural decisions can be defensible under the conditions known at the time and only later become obstacles to further evolution.

The problem, therefore, is not pragmatism. The more important question is what happens when local optimization is not balanced by a sufficiently strong structural counterforce over time. One shortcut does not make a Big Ball of Mud, neither does one workaround, and even deliberately accepted Technical Debt can be a reasonable investment decision.

Thousands of shortcuts that are never taken back can eventually become the architecture itself.

What Is Not Taken Back Becomes Architecture

The first special solution is usually still clearly recognizable as a special solution. There may even be a comment next to it:

TODO: Consolidate after the release.

After the release, however, comes the next feature, then the next customer, and eventually the next deadline. Meanwhile, another change already uses the original special solution, and perhaps a second team has started to build on its behavior. What was intended as a deliberately limited workaround gradually becomes part of the regular system structure.

“We are doing this temporarily” becomes “This is how it works in our system,” and eventually “We have always done it this way.” That transition captures an important part of architecture erosion:

Architecture is not created only by what we deliberately design. It is also created by what we fail to take back over the years.

Foote and Yoder’s Piecemeal Growth does not describe incremental software development as inherently wrong. A living system has to be extended step by step while it continues to operate. The authors do, however, point to the risk that urgent local requirements can displace long-term architectural concerns, and they therefore place recurring Consolidation Phases, refactoring, and repair alongside expansion.

Not every extension requires a major cleanup afterwards. A long-lived system does, however, need mechanisms through which its structure can respond to what has been learned. Requirements change, teams learn, technical platforms evolve, earlier assumptions turn out to be wrong, and domain boundaries shift. If everything around a system continues to evolve while its internal structure is only extended and never reconsidered, the system increasingly preserves its own past.

Operational Pressure Changes the Decision Horizon

A deadline does not destroy an architecture. It does, however, change which solution appears rational at a particular moment. Under operational pressure, the time horizon becomes shorter: instead of asking what the structure of an area should look like in three years, a team may first need to answer what can be delivered reliably by Friday. That can be entirely legitimate.

Research on time pressure in software development paints a correspondingly nuanced picture. A systematic review by Kuutila, Mäntylä, Farooq, and Claes shows that time pressure cannot meaningfully be reduced to a simple formula such as “more pressure automatically produces worse software”; context, intensity, and the type of pressure matter. The problem is therefore not the individual deadline, but an environment in which the decision horizon permanently ends at the next one.

The same applies to the often-criticized pressure to deliver features. A feature has a customer, a concrete requirement, a ticket, a deadline, and visible value. Revenue may depend on it, or a regulatory requirement, or a contractual commitment. Structural consolidation, by contrast, often competes with a much more abstract benefit: a future problem that may never occur because the consolidation prevented it. Nobody can point to a roadmap and show the incident that will not happen four years from now because of a refactoring performed today.

Choosing the feature can therefore be entirely understandable economically. What becomes critical is not the individual prioritization but its repetition over years. Studies on Technical Debt accordingly identify time and deadline pressure, as well as prioritizing new functionality over structural quality, among frequently reported causes. None of this establishes an automatic causal chain to a Big Ball of Mud. The more interesting question is:

What happens when the same prioritization wins for years?

A Big Ball of Mud does not have to begin with a bad decision. What matters is how many decisions interact over time.

Who Represents the Structure?

At this point, the question about the architect is an obvious one: Wouldn’t a good architect have prevented all of this? Perhaps — but perhaps not. A system does not necessarily need a person with the title “Software Architect.” What it needs is a sufficiently effective counterforce to permanent local optimization.

That counterforce can come from experienced developers and Tech Leads, explicit architecture rules, reviews, automated architecture tests or Fitness Functions, good regression tests, shared technical principles, and continuous refactoring. It can also be embodied by an architecture role with time, mandate, and influence. The important point is not the particular form it takes, but whether long-term structural quality actually carries weight when decisions are made.

An architect alone does not prevent a Big Ball of Mud. A person who is nominally responsible but has neither time nor decision-making authority can hardly protect the structure of a system over the long term. Conversely, experienced teams without a formal architecture role can build excellent systems for many years.

What matters less is the title “Architect” than whether long-term structural quality has an effective voice in the system.

The systematic mapping study by Li, Liang, Soliman, and Avgeriou is particularly relevant here. Their analysis of 73 studies on Architecture Erosion explicitly concludes that non-technical causes should be taken as seriously as technical ones. Architecture Erosion therefore cannot be meaningfully reduced to code quality or individual design decisions alone.

Brilliance in One Discipline Does Not Replace Another

This brings me back to the product whose origins I later came to understand myself. Its technical foundation emerged from exceptionally demanding scientific work. The person who developed the original approach solved a problem that very few people would have been capable of solving at all. Someone else then recognized the economic potential of the idea. That also requires expertise: understanding markets, identifying opportunities, taking risks, and turning a technical possibility into a product.

Both were successful. Both, however, are different from the question of how to structure a software system that will be evolved by changing teams over decades.

Expertise is domain-specific.

An excellent mathematician is not automatically a software architect, and a visionary entrepreneur is not automatically an expert in evolutionary software architecture. Conversely, I would not presume that I could make a cryptographer’s scientific decisions or a successful founder’s market decisions better simply because I know how to structure software systems. The problem begins when organizations confuse these forms of expertise or assume that exceptional intelligence and extraordinary personal effort can compensate for structural deficiencies indefinitely.

Surprisingly often, that works for quite a while. Very good developers can keep difficult systems manageable for a long time because they understand edge cases, know historical decisions, build migrations, rescue releases, and find paths through structures that no longer make sense to others. That is competence — and that competence can paradoxically contribute to the limits of the system remaining partially hidden. As long as highly capable people keep finding another solution, the system continues to produce results. From the perspective of the next release, there is therefore initially a good reason to continue in exactly the same way.

When You Work Against the Platform

Another mechanism becomes particularly visible in long-lived frameworks and platforms, although it is by no means specific to any particular frontend framework. A platform provides concepts, extension points, and lifecycles. A team may not yet understand one of these mechanisms well enough, may consider it unsuitable, or may simply not have enough time under pressure to integrate it properly. So a custom solution emerges — and that solution may work perfectly well.

There is nothing inherently wrong with that. Frameworks do not make infallible architectural decisions, and custom abstractions can be sensible or even necessary. What matters is what happens afterwards. The platform evolves, concepts change, APIs are replaced, and earlier mechanisms are deprecated or removed. Eventually, the custom solution no longer fits the intended evolutionary path and must either be adapted — or the new platform mechanism is bypassed again.

If the second path is chosen repeatedly, a reinforcing pattern can emerge:

Deviation → upgrade problem → workaround → greater deviation → greater upgrade problem

Eventually, the team is no longer maintaining only its product, but parts of a parallel platform of its own making as well. The relevant distinction is therefore not whether every framework recommendation is correct, but the long-term decoupling from the evolutionary path of the chosen platform.

This, too, was not one major mistake in the system I experienced. After a technology transition, the team had limited experience with the new platform while facing real delivery pressure. Where intended mechanisms were not understood, not accepted, or could not be integrated in time, custom solutions emerged. They worked, were therefore kept, and later had to be protected or adapted again as the platform evolved.

Even then, nobody could have pointed at one commit and said: This is where the Big Ball of Mud was built. Every change had a story.

Teams Leave. Decisions Stay.

While all of this happens, the organization changes. Developers move to another team or another company, Tech Leads leave, Product Owners change, executives come and go, strategies are reformulated, and technologies gain or lose relevance. The code remains.

When people leave, more than technical skill can disappear. Parts of the knowledge about why a particular decision was made can disappear as well. A developer may have known exactly that a solution was intended to exist only until another specific problem had been resolved. Years later, nobody remembers that problem, but the solution is still there. Its meaning changes: a consciously accepted exception can turn into an apparent convention on which the next generation continues to build.

Software often has a longer memory than organizations do. The code preserves decisions whose original rationale has long since disappeared.

Up to this point, the article has described a classic erosion path: a system grows, changes, accumulates decisions, and loses part of its original structure over time. But that is not the only path.

Sometimes You Inherit the Big Ball of Mud

Not every team starts working on a system while it is still structurally healthy. Sometimes the Big Ball of Mud is already there. A new team inherits an existing application — after an internal reorganization, through a change of service provider, or as part of a new project. Perhaps the next version of a long-lived public information system is put out to tender and a different contractor wins the contract.

That team now sits in front of a codebase whose decisions it did not make. The modules, dependencies, missing tests, and historical workarounds already exist; only part of the context in which they were created has disappeared. That changes the question of blame fundamentally. The new team did not build the Big Ball of Mud, but it still has to work inside it.

That raises a different question:

Does this team actually have a mandate to fix the structural problems — or only a mandate to implement the next feature inside them?

A Project Ends. The Software Does Not.

The conflict becomes particularly visible when long-lived software is organized into time-limited projects. Organizationally, version 1 may be completed and formally accepted; technically, the same system continues to live. Version 2 may have a new contract, a new budget, and a new contractor, but it still inherits every technical decision from version 1. The project boundary exists in the contract — it does not exist in the code.

That sounds trivial, but in practice it changes the incentives significantly. One contractor develops V1, the system fulfills its functional purpose, and the project is accepted. A few years later, V2 is commissioned and a new contractor takes over. The new team discovers that important areas are poorly documented, tests are missing, and the structure has serious deficiencies. Its technical assessment may be:

Before we continue building on this for the long term, we need to consolidate parts of it.

The commercial assignment, however, may simply say:

Deliver V2.

That creates a sentence that is not at all absurd in such a situation:

“We are not being paid to refactor.”

That is not automatically an excuse. It can be an entirely accurate description of the contract. The architecture problem is not unknown — it simply has no funded owner.

This creates a difficult economic problem for the new contractor. It inherits the technical past of the product while its contract may primarily fund the next functional extension. Should it repair the predecessor’s architecture at its own expense? Should it explain that a substantial part of the budget ought to go into structural work rather than visible new functionality? And what happens if that work was not part of the tender and competing vendors therefore calculated lower prices?

Under those conditions, continuing to build locally can once again be the economically rational choice. Structurally, this is almost the same logic as feature pressure inside a company — only with a harder boundary. The contractor optimizes for its scope of work, the domain side for required functionality, project management for schedule, budget, and acceptance, and procurement for a compliant process. Every participant can fulfill their respective role reasonably well while long-term architecture quality disappears between those responsibilities.

Every project can be successful while the product erodes at the same time.

The local unit is no longer a feature or a team. It is an entire project.

Public Procurement Makes the Conflict Especially Visible

This mechanism is not unique to the public sector. Private companies also change service providers, split budgets into projects, or buy software development in packages. In the public sector, however, the conflict becomes particularly visible because procurement, competition, budgeting logic, and software development have to be satisfied at the same time.

Research on public-sector information systems describes exactly these tensions. Alaranta and Jarvenpaa studied the transition from a long-term IT provider to a new one in a Finnish public organization as early as 2010. The switch was not caused by poor performance from the incumbent vendor, but by the public procurement process. Their case study focuses on the loss of experiential knowledge during the transition from one provider to another.

That is an important distinction from a purely technical handover. Source code can be copied, tickets can be exported, and documentation can be transferred. Experiential knowledge cannot be exported completely as an artifact.

Ghezzi and colleagues frame the problem even more fundamentally: software has both the ability and the need to change continuously, while public information systems are simultaneously constrained by competition and budgeting processes. Two different models of time therefore collide. The software evolves continuously; funding, procurement, and responsibilities are often organized in periods and projects.

Moe, Newman, and Sein likewise identify an institutional tension in their study of public information-systems procurement. For complex systems, a contracting authority often needs intensive dialogue to understand and specify requirements adequately. Procurement rules, meanwhile, limit that dialogue for good reasons because transparency and equal treatment of vendors must be preserved.

The problem therefore cannot be reduced to the claim that public authorities simply need to write better tenders. The requirements of lawful and fair procurement and the learning, evolutionary nature of complex software are genuinely in tension in some situations. That is precisely why long-term technical ownership becomes more important, not less.

Who Owns the Architecture Between Two Tenders?

If contractors can change, someone else must represent the structure of the system across those changes. The first contractor cannot do so permanently because its contract ends. The next one did not make the original decisions. The domain organization may have excellent domain expertise but not necessarily deep software-architecture expertise. A project manager can be excellent at budgets, schedules, and stakeholder coordination without being able to evaluate a dependency structure or test strategy professionally. Procurement has a different responsibility again.

This does not mean that public-sector clients must be technically incompetent. It simply means that long-lived software architecture requires a capability that does not automatically emerge from conventional project organization.

The contractor can change. Architecture ownership must not start over every time.

That ownership does not mean that every line of code has to be written in-house. Development can continue to be outsourced, and teams and service providers can change. But somewhere on the client side, enough technical competence must remain over the long term to represent domain and technical boundaries, define quality requirements, consciously accept or reject Technical Debt, and decide which remediation work needs to be part of a tender from the outset.

It also means making binding decisions about which tests and automated quality mechanisms must exist at every handover, which architecture decisions remain in force, which structural risks a new contractor is expected to assume, and what condition is acceptable for formal acceptance in the first place. That is more than project management. It is product and architecture ownership across contract boundaries.

Project and contract boundaries divide the organization. The technical past of the product crosses those boundaries completely.

Outsourcing Is Not the Problem

A simple conclusion at this point would be that software should never be outsourced. That would be too simplistic as well. External development can provide access to specialized expertise, make capacity available flexibly, and support organizations with capabilities that do not make sense to build internally. The real risk is not the existence of an external service provider, but losing the ability to steer the technology along with outsourcing the implementation.

A contractor works on the system every day. It understands its edge cases, knows where documentation and reality diverge, and knows which test provides safety only on paper or which module is best left untouched. If that knowledge exists exclusively with the supplier, a later switch becomes more difficult. This does not require a deliberate lock-in strategy; it is enough for the client to fail to build or retain sufficient technical competence over the years.

That is also why more recent research on backsourcing is interesting. Lassenius, Mohagheghi, and Seide Molléri studied a large public organization that brought responsibility for a substantial part of its software development back in-house. Reported outcomes included a stronger sense of system ownership, more control over the lifecycle, faster delivery, and a stronger focus on Technical Debt. At the same time, the study shows how demanding it is to rebuild and retain the required capabilities.

The point is therefore not that insourcing is inherently better. It is this:

An organization can outsource software development without outsourcing its ability to own the technology.

When Nobody Is Paid to Refactor

The sentence “We are not being paid to refactor” therefore takes on a second meaning. In the first erosion path described in this article, refactoring was postponed because the next feature appeared more urgent. In the second path, refactoring may already lie outside the agreed scope of work. The team may understand the structural need perfectly well and even have the expertise to address it, while the commercial structure of the project leaves no room for the work.

That does not make the situation inevitable. Technical quality, maintainability, tests, documentation, architecture rules, and remediation work can all be part of tenders and contracts. But for that to happen, the client first has to recognize what quality it needs, be able to describe it, and have the expertise to evaluate whether it has actually been delivered.

Quality can only be commissioned effectively if someone on the client side understands what quality is actually required.

That brings the argument back to architecture ownership.

Two Paths — the Same Blind Spot

The classic erosion path and the project-by-project handover path differ significantly. In the first, a system grows into its problems over years; in the second, a new team inherits part of those problems on its first day. In the first, workarounds gradually lose their exceptional status; in the second, they may simply look like “the existing system” from the beginning. In the first, the same organization repeatedly postpones refactoring in favor of new requirements; in the second, a new contractor may recognize that refactoring is necessary while having no mandate to perform it at all.

And yet both paths share the same core problem:

Structural decisions often outlive the responsibility that was supposed to govern them.

Feature teams dissolve, architects leave, contracts end, service providers lose the next tender, and project phases are formally accepted. The code, the dependencies, and their consequences remain. Long-term architecture ownership is therefore not simply a role in an organization chart; it is a continuity function. Someone — or an effective combination of people, rules, and automated mechanisms — has to ensure over time that the sum of local decisions remains compatible with a viable overall structure.

When the Past Dictates the Next Decision

As erosion increases, the space of future decisions changes as well. A new requirement no longer starts from a blank page. It encounters existing coupling, special solutions, custom mechanisms, migrations, and historical assumptions. A reinforcing loop can emerge:

Time pressure
→ local solution
→ additional structural dependency
→ the next change requires more analysis
→ effort and risk increase
→ time pressure rises
→ another local solution becomes particularly attractive

In a multiple-case study across large companies, Martini, Bosch, and Chaudron observed precisely these temporal dynamics around Architectural Technical Debt. In the companies they studied, refactoring was often triggered reactively by crises rather than by keeping structural debt continuously visible and manageable.

The loop is not inevitable. It can be interrupted, but doing so requires a counter-movement: consolidation, refactoring, architecture work, deliberate removal of structures that are no longer useful — and above all, someone who actually has responsibility, time, and budget for that work.

Local solutions can change future decisions: as the system becomes harder to change, the pressure to optimize locally again next time increases.

The past does not determine the future completely, but it changes its price.

And Now Local Decisions Become Even Faster

Coding Agents initially change one variable in this underlying problem more than anything else: speed. An agent can produce a locally working solution at impressive speed. If ownership, boundaries, and architecture rules are explicit, that is a major advantage. If those orientation points are missing, an agent also has to reinterpret with every task which of the many possible local solutions is structurally desirable.

An agent can find good local solutions very quickly. Historically, that was already part of the problem.

This series will return to that topic in much more detail elsewhere.

Who Is to Blame?

After all these stories, the question of blame is unavoidable. “Nobody” would be a convenient answer, but it would dissolve responsibility completely. Decisions have owners: developers are responsible for their changes, technical leadership for technical direction, management for priorities, and clients for requirements and contracts. Contractors, in turn, are responsible for the quality of the work they agreed to deliver.

“Everyone” would be just as unhelpful. People act at different times with different information, constraints, budgets, and time horizons. The developer building a workaround may know the deadline but not the requirements of the next five years. The Product Owner sees the customer waiting for a feature but not every technical dependency the change will create. The architect knows the long-term target structure but may lack the mandate to defend it against every short-term priority. A new contractor may recognize a structurally compromised system but have a budget only for the next version.

Project management and software architecture are different disciplines as well. A project manager can perform their role professionally and still lack the depth required to assess a complex dependency structure or the viability of a test strategy. That is not personal failure; it is first and foremost a question of roles and the expertise those roles require.

That is why the Big Ball of Mud as an overall condition often cannot be meaningfully reduced to one person or one decision. That is the distinction between responsibility and blame: decisions can be analyzed critically without turning the story into one about culprits.

Nobody Built It

When I look back today at systems that became part of the reason for writing this series, I find it difficult to identify the moment when someone could clearly have said: Now it has become a Big Ball of Mud. The successful proof of concept was not that moment; without it, the product might never have existed. The decision to turn it into a product may also have been entirely correct economically. The first workaround probably solved a real problem, the technology transition had understandable reasons, and the deferred refactoring may genuinely have lost to a customer who mattered more at that particular moment.

With an inherited system, the question becomes even harder. Is Contractor B to blame for continuing to build on V1 if its assignment simply says to deliver V2? Is Contractor A to blame if it met exactly the quality requirements that were commissioned and accepted at the time? Is project management responsible for a technical structure if it lacks both the role and the expertise to represent architecture quality across multiple procurement cycles?

That is precisely why the emergence of a Big Ball of Mud is so interesting:

It is not one mistake. It is the interaction of many locally logical decisions over years.

Sometimes, another factor is added:

An organization can divide its responsibility into projects. The software system does not adopt those boundaries.

Foote and Yoder asked as early as the late 1990s what forces lead good programmers to produce structurally problematic systems. Their description of Throwaway Code, Piecemeal Growth, Keep It Working, Shearing Layers, consolidation, and eventually Reconstruction reads less like a catalogue of individual failures than a description of evolutionary forces acting on long-lived software.

Modern research on Architecture Erosion, Architectural Technical Debt, outsourcing, and public-sector information systems expands that picture. It identifies technical and non-technical influences, competing short- and long-term goals, knowledge loss during handovers, institutional tensions in procurement, and the value of long-term system ownership.

A Big Ball of Mud can therefore be understood as an emergent result: many people change a system over a long period of time, and each change reacts to the situation created by earlier changes. Teams, contracts, and organizations change while technical decisions continue to live on. Without continuous structural feedback, the sum can eventually take a form that nobody ever designed as a target state.

Everyone may have contributed a piece, while some merely carried forward a piece that was already there. Nobody drew the result, and nobody decided in a single day to dissolve its boundaries.

And yet many people — usually for understandable reasons — contributed a small piece to it.

Architecture Erosion is not an event. It is a process. And sometimes the most important thing an organization can do to counter it is remarkably unspectacular:

Make sure responsibility for the architecture outlives the next feature, the next project, the next team, or the next contract.

Sources

• Brian Foote, Joseph W. Yoder: Big Ball of Mud. Technical Report WUCS-97-34, Department of Computer Science, Washington University, originally presented at the Fourth Conference on Pattern Languages of Programs (PLoP ’97), 1997; later published as Chapter 29 in Neil Harrison, Brian Foote, Hans Rohnert (eds.): Pattern Languages of Program Design 4. Addison-Wesley, 2000.
• Ruiyin Li, Peng Liang, Mohamed Soliman, Paris Avgeriou: Understanding Software Architecture Erosion: A Systematic Mapping Study. Journal of Software: Evolution and Process 34(3), 2022, e2423. DOI: 10.1002/smr.2423.
• Antonio Martini, Jan Bosch, Michel Chaudron: Investigating Architectural Technical Debt Accumulation and Refactoring over Time: A Multiple-Case Study. Information and Software Technology 67, 2015, pp. 237–253. DOI: 10.1016/j.infsof.2015.07.005.
• Roberto Verdecchia, Philippe Kruchten, Patricia Lago, Ivano Malavolta: Building and Evaluating a Theory of Architectural Technical Debt in Software-Intensive Systems. Journal of Systems and Software 176, 2021, 110925. DOI: 10.1016/j.jss.2021.110925.
• Miikka Kuutila, Mika Mäntylä, Umar Farooq, Maëlick Claes: Time Pressure in Software Engineering: A Systematic Review. Information and Software Technology 121, 2020, 106257. DOI: 10.1016/j.infsof.2020.106257.
• Rodrigo Rebouças de Almeida, Christoph Treude, Uirá Kulesza: What’s Behind Tight Deadlines? Business Causes of Technical Debt. IEEE/ACM International Conference on Cooperative and Human Aspects of Software Engineering (CHASE), 2023.
• Robert Ramač et al.: Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry. Journal of Systems and Software 184, 2022, 111114. DOI: 10.1016/j.jss.2021.111114.
• Martin P. Robillard: Turnover-Induced Knowledge Loss in Practice. ESEC/FSE ’21, 2021, pp. 1292–1302. DOI: 10.1145/3468264.3473923.
• Maria Alaranta, Sirkka L. Jarvenpaa: Changing IT Providers in Public Sector Outsourcing: Managing the Loss of Experiential Knowledge. 43rd Hawaii International Conference on System Sciences (HICSS), 2010. DOI: 10.1109/HICSS.2010.101.
• Reetta Ghezzi, Aapo Koski, Janne Lautanala, Mikko Lehtisalo, Manu Setälä, Tommi Mikkonen: Towards Sustainable Software for Public Sector Information Systems. IEEE/ACM International Conference on Software and System Processes (ICSSP), 2023, pp. 86–91. DOI: 10.1109/ICSSP59042.2023.00019.
• Carl Erik Moe, Michael Newman, Maung Kyaw Sein: The Public Procurement of Information Systems: Dialectics in Requirements Specification. European Journal of Information Systems 26(2), 2017, pp. 143–163. DOI: 10.1057/s41303-017-0035-4.
• Josep M. Marco-Simó, Joan A. Pastor-Collado: IT Outsourcing in the Public Sector: A Descriptive Framework from a Literature Review. Journal of Global Information Technology Management 23(1), 2020, pp. 25–52. DOI: 10.1080/1097198X.2019.1701357.
• Casper Lassenius, Parastoo Mohagheghi, Jefferson Seide Molléri: Bringing it Home: Successful Backsourcing of Software Development in the Public Sector. Empirical Software Engineering 30, 170, 2025. DOI: 10.1007/s10664-025-10722-1.