The Hidden Cost of Software Complexity: Defects, Developer Productivity, and Engineering Turnover

Key takeaways

• Architectural complexity is created when dependencies, weak modularity, and broken abstractions make a system difficult to understand and change.
• In the research setting examined, work in the most architecturally complex parts of the codebase was associated with roughly three times the defect density and a near-halving of developer productivity.
• Architectural complexity is not only a software-quality problem; it can also affect engineering capacity, predictability, morale, and retention.
• Organizations can use architectural analysis to identify complexity hotspots, estimate their operational cost, and prioritize modernization based on evidence. Silverthread's CodeMRI® Discovery is built on this research and assesses the technical health of a software portfolio in days rather than months.

Executive summary

Software architecture affects far more than the elegance of a codebase.

When a system becomes difficult to understand, difficult to change, and difficult to test, the consequences reach across the organization. Defects take longer to resolve. Delivery slows. Engineering teams spend more time navigating dependencies and less time creating new value. Over time, the most difficult parts of the system can become a source of frustration, stalled modernization, and talent risk.

This is the cost of architectural complexity.

That claim is not anecdotal. It rests on more than fifteen years of research conducted at MIT and Harvard Business School by Daniel Sturtevant, Carliss Baldwin, and Alan MacCormack — the three researchers who founded Silverthread, Inc. in 2013 to commercialize that work. Sturtevant, Baldwin and MacCormack serve as co-founders and experts. The findings below come directly from that research program.

Research conducted across eight releases of a mature commercial software product-Sturtevant’s MIT doctoral dissertation- found a strong relationship between architectural complexity and three material outcomes:

• Defect density: the most architecturally complex files experienced roughly three times the defect density of the least complex files.
• Developer productivity: developers working in the most complex regions of the codebase were projected to experience a near-halving of productivity compared with similar developers working in the least complex regions.
• Engineering turnover: developers whose work was concentrated in the most architecturally complex parts of the system had a substantially higher likelihood of leaving the organization.

These findings do not mean that every complex system is unhealthy or that every central component should be rewritten. Mature systems need shared services, core capabilities, and integrated workflows.

They do mean that architecture should be treated as a measurable business concern. When an organization can see where complexity is concentrated and connect it to defects, delivery capacity, and engineering experience, it can make far better modernization decisions.

What is architectural complexity?

Architectural complexity is the complexity created by the way the parts of a software system are connected.

It is distinct from the complexity of an individual function, class, or file. A component can be relatively simple on its own yet still be difficult to change because it is deeply embedded in a network of dependencies.

Architectural complexity often appears when a system loses, or never establishes, clear:

• Modularity: components can be changed with limited impact on others.
• Hierarchy: the system has understandable levels of responsibility and control.
• Abstraction layers: developers can work at one level without needing to understand every implementation detail below it.
• Boundaries and interfaces: teams can make changes through predictable contracts rather than undocumented dependencies.

When those patterns break down, the system becomes harder to reason about. A developer making a local change may need to understand several other services, data structures, libraries, APIs, or application behaviors before they can act safely.

That creates cost even when no visible outage or defect has occurred.

Why software complexity becomes a business problem

Most organizations recognize architectural complexity only after it becomes operationally painful.

The signals are familiar:

• Engineering estimates become increasingly difficult to trust.
• “Small” changes expand into large, cross-team efforts.
• Release testing grows because the impact of a change is uncertain.
• Defects appear in areas seemingly unrelated to the original change.
• Modernization initiatives repeatedly uncover hidden work.
• Developers avoid making changes to parts of the system perceived as fragile.
• High-value engineers spend disproportionate time on maintenance and defect remediation.

These are not simply engineering inconveniences. They affect the organization’s ability to respond to customers, compete in the market, adopt new platforms, address security requirements, and deliver strategic initiatives.

A business cannot move faster than its ability to change its systems safely.

The difference between code complexity and architectural complexity

Traditional software-quality measures often focus on the internal characteristics of individual pieces of code. For example, they may assess:

• File size
• Lines of code
• Cyclomatic complexity
• Code duplication
• Static-analysis violations
• Test coverage
• Framework currency

These measures are valuable. They can reveal code that is difficult to understand, test, or maintain.

But they do not fully explain how a change will travel through a system.

Architectural complexity considers the relationships among components. It asks questions such as:

• How many components directly or indirectly depend on this one?
• How many other components does it rely upon?
• Is it part of a tightly interconnected group where changes can circulate or propagate?
• Can teams modify it locally, or must they coordinate broadly across the system?
• Does it sit within a shared dependency path that increases the potential impact of failure or change?

Both perspectives matter. A highly complex file can create local risk. A tightly coupled architectural core can create systemic risk.

The most accurate view of software health considers both. This is why CodeMRI® measures code quality, design integrity, duplication, and architectural conformance together rather than treating them as separate exercises.

Research evidence: the cost of working in architecturally complex code

Daniel J. Sturtevant’s doctoral research, System Design and the Cost of Architectural Complexity, examined a mature commercial software product over eight releases.

The research measured architectural complexity using dependency-based methods developed to identify the role of source files within the larger network of a software system. Files were classified according to their structural role, including peripheral files and files located in the highly interconnected architectural core.

The research then compared these architectural measures with three outcomes that matter to software organizations: defects, developer productivity, and turnover.

1. Architecturally complex code had substantially more defects

Files in the architectural core experienced a significantly higher rate of defect-related activity than files on the periphery.

After accounting for factors including file size, file age, development activity, and code-level complexity, the research found that the most architecturally complex code had approximately three times the defect density of the least complex code.

The difference was even more pronounced when architectural and code-level complexity were considered together. A highly complex file located in the architectural core was projected to experience far more defect activity than a low-complexity file on the periphery.

This matters because defects are rarely isolated costs. They consume developer time, delay planned work, increase testing requirements, affect customer confidence, and create follow-on risk in future releases.

2. Architectural complexity reduced developer productivity

The research also examined how the architectural location of a developer’s work affected productivity.

This is a crucial distinction. A system may be large, but developers do not work everywhere equally. Some spend most of their time in new, relatively contained areas. Others work continuously in the system’s most interconnected legacy regions.

In the study, developers working in the least architecturally complex regions were projected to produce substantially more than comparable developers working in the most complex regions.

For feature and non-defect work, the model projected a decline from approximately 10,655 lines of change per release for a developer working entirely in the periphery to approximately 6,083 lines for a similar developer working entirely in the core.

For overall work, accounting for a typical mix of features and defect remediation, the results also showed a strong decline in output as work moved from peripheral to core regions.

The broader finding was a near-halving of developer productivity between the least and most architecturally complex areas of the system.

Lines of code are not a complete measure of developer value, and no serious leader should use them as an individual performance metric. In this research, they were a way to measure the volume of development activity completed under comparable conditions.

The practical conclusion is simpler: when developers must work in a highly coupled architectural core, more of their time is consumed by understanding, coordination, rework, and defect-related effort.

3. Architectural complexity was associated with higher engineering turnover

Perhaps the most consequential finding was the relationship between architectural complexity and staff turnover.

The research examined 108 developers over the study period and subsequent years, controlling for factors including tenure, managerial status, productivity, the share of work devoted to bug fixes, work in new versus legacy files, and code-level complexity.

Developers with a greater concentration of work in architecturally complex core files were significantly more likely to leave the firm than peers whose work was concentrated in less complex regions.

In model simulations, a developer working entirely in peripheral code had an estimated 2% probability of leaving, while a developer working entirely in the architectural core had an estimated 31% probability. The study’s conclusion characterized the difference as an order-of-magnitude increase in turnover risk.

The research does not claim architecture is the sole reason a person leaves a job. Compensation, management, career opportunity, team dynamics, workload, and market conditions all matter.

But it identifies an important and often overlooked operational reality: people can become trapped in systems that are chronically difficult to change. When talented engineers spend much of their working life fixing problems created by hidden dependencies and fragile architecture, the organization pays twice—first in lost productivity, then in lost expertise.

Why highly coupled cores create drag

A tightly coupled architectural core creates a form of operational gravity.

Work is pulled toward it because critical business functionality, shared data, or long-lived system logic often resides there. At the same time, each change becomes harder because developers must account for more relationships and a greater potential blast radius.

The result is a reinforcing cycle:

1. A tightly coupled area creates more defect and maintenance work.
2. More defect work reduces time available for improvement and modernization.
3. The area becomes harder to understand as knowledge concentrates in a smaller group of experienced developers.
4. Teams become more cautious, testing grows, and delivery slows.
5. Developers become frustrated by the difficulty of making meaningful progress.
6. Turnover and knowledge loss make the core even harder to change.

That is why architectural debt should not be treated as a static backlog of technical tasks. It is a dynamic business risk that can compound over time.

AI-assisted development makes architectural visibility more important

AI coding tools can help teams create and modify code more quickly. Used responsibly, they can improve engineering productivity and reduce friction in many development tasks.

But AI does not remove the underlying architecture.

If a system is tightly coupled, increased code-generation velocity can create more changes flowing through the same fragile dependency network. That can increase the volume of work without improving the system’s long-term ability to evolve.

The leadership question is not whether engineers are using AI. It is whether the organization can see the architectural consequences of faster change.

Leaders should be able to ask:

• Are AI-assisted changes remaining local, understandable, and testable?
• Are developers increasing delivery speed without increasing coupling or hidden dependency risk?
• Which areas of the system are structurally safe to change quickly?
• Which areas require additional governance, architectural review, or targeted modernization first?
• Is the organization using AI to accelerate future capability—or to accelerate the accumulation of architectural debt?

Architectural intelligence provides the evidence needed to answer those questions.

How to turn architectural complexity into a modernization strategy

The answer is not to ask engineering teams to “clean up technical debt” whenever capacity permits. That approach is too broad, too subjective, and too easy to defer.

A stronger approach connects architecture to operational outcomes.

1. Map dependencies across the system

Identify direct and indirect dependencies among source-code components, applications, services, data stores, and interfaces. The goal is to understand how a change can propagate—not simply to create a more detailed diagram.

2. Identify the architectural core and other hotspots

Determine which components are highly interconnected, widely shared, or exposed to broad change impact. These are the places where architecture is most likely to affect delivery cost, risk, and resilience. CodeMRI® Discovery uses heatmap displays to surface and prioritize technical debt hotspots across a system.

3. Connect architecture to delivery and quality data

Compare structural complexity with data such as defect activity, maintenance effort, change failure, release delays, developer allocation, and support burden. . CodeMRI® pairs this with benchmarking and economic analysis, allowing a system to be compared against thousands of others rather than judged in isolation. This makes the cost visible in business terms.

4. Prioritize targeted, incremental refactoring

A complete rewrite is rarely practical for a mature system. Instead, focus on reducing coupling in the areas where improvement will create the greatest benefit.

That may mean creating clearer interfaces, extracting shared functionality, separating responsibilities, reducing cyclic dependencies, or modularizing a critical region over time. . CodeMRI® Modernize is designed to support exactly this pattern,  incrementally transforming legacy code into modular architecture while day-to-day development continues.

5. Measure whether the architecture is improving

Modernization should produce evidence of progress. Organizations should be able to see whether the architectural core is shrinking, dependency risk is declining, defects are becoming more contained, and teams are delivering changes with greater predictability.

‍

Frequently asked questions

What is architectural complexity in software?

Architectural complexity is the complexity created by relationships among software components. It increases when dependencies, weak modularity, and unclear boundaries make it difficult to understand or safely change one part of a system without affecting others.

How is architectural complexity different from technical debt?

Architectural complexity is one major source of technical debt. Technical debt includes many issues, such as outdated technology, missing tests, or poor documentation. Architectural complexity specifically concerns the structural dependencies that increase the future cost and risk of change.

Can software architecture affect developer productivity?

Yes. Developers working in tightly coupled, highly interconnected areas often need more context, coordination, testing, and rework to complete changes. Research cited here found a strong association between work in architecturally complex code and lower developer productivity.

Can architectural complexity contribute to engineering turnover?

It can be a contributing factor. Research conducted in one mature commercial software environment found a strong association between developers’ concentration of work in the architectural core and the likelihood of leaving the firm. Architecture is not the only influence on retention, but difficult-to-change systems can materially affect the developer experience.

Does high architectural complexity mean a system should be rewritten?

Not necessarily. Mature systems often contain important shared and central capabilities. The right response is usually targeted, incremental refactoring based on evidence of where complexity is creating the greatest cost, defect risk, or delivery constraint.

How can an organization measure architectural complexity?

Organizations can analyze direct and indirect dependencies among software components. This helps identify tightly coupled cores, shared dependencies, cyclic relationships, and areas where a change may propagate broadly through the system. The results can be combined with operational data to prioritize modernization investments. Silverthread's CodeMRI® Suite applies these methods commercially, measuring code quality, design integrity, duplication, and architectural conformance across systems.

Architecture is a capacity decision

The cost of architectural complexity does not sit only in an engineering backlog.

It appears in the organization’s ability to deliver, adapt, retain talent, and respond to change. It is visible in missed opportunities, slower modernization, recurring defect work, and the exhaustion of the people asked to maintain the system.

The good news is that architectural complexity can be measured. Once leaders can see where dependency risk is concentrated and connect it to business outcomes, they can stop treating modernization as an act of faith.

They can make a focused investment in a software system that is easier to change, safer to operate, and better able to support the business for the long term.

Silverthread helps technology leaders make software architecture visible, measurable, and actionable—so they can identify structural risk, quantify the cost of complexity, and prioritize modernization where it will have the greatest impact.. The company was founded in 2013 by Daniel Sturtevant, Carliss Baldwin, and Alan MacCormack to commercialize the MIT and Harvard Business School research described in this article, and its CodeMRI® Suite has been applied to more than 7,000 codebases.

Foundational research

Sturtevant, Daniel J. System Design and the Cost of Architectural Complexity. Doctoral dissertation, Massachusetts Institute of Technology, Engineering Systems Division, 2013