Three Hidden Traps That Shape Software Engineering Decisions

Software engineering is often seen as a technical field focused on designing systems, writing code, selecting architectures, defining APIs, and optimizing for performance, scalability, and maintainability. However, many of the most challenging problems are not technical, but human.

As engineers advance into leadership roles such as senior engineer, Staff Engineer, architect, or engineering manager, the challenge extends beyond technical solutions. Leaders must also understand how people make decisions, how teams respond to change, and how individual behavior can influence software quality.

Humans are not always rational. We depend on habits, shortcuts, intuition, experience, and assumptions. While these can improve efficiency, they may also lead to decisions that don't align with requirements, constraints, or long-term goals.

A team may retain a design simply because “we have always done it this way.” Engineers might accept poor code quality if the existing codebase is already disorganized. Teams may also select a complex architecture because complexity appears more robust, even when a simpler solution would suffice.

While these decisions may seem minor individually, over time they can impact more than a single implementation. They may influence team behavior, increase technical debt, reduce maintainability, and shape the system’s architecture.

This article examines three common behavioral traps that affect software engineering decisions: status quo bias, the broken windows effect, and complexity bias. We will also discuss how engineers and technical leaders can identify these patterns and foster more deliberate, evidence-based decisions.

What Are Cognitive Biases, and How Do They Affect Software?

Cognitive biases are systematic patterns in how people interpret information, evaluate alternatives, and make decisions. Rather than random mistakes, they are mental shortcuts that help us act quickly but can also influence our judgment without our awareness.

This is especially relevant in software engineering, where decisions are often made under uncertainty, time constraints, incomplete information, and the influence of prior experience. Engineers rarely evaluate every alternative from scratch. Instead, we reuse patterns, rely on intuition, trust familiar technologies, and simplify complex situations to maintain progress.

Most of the time, this is useful. Software development would be impossibly slow if every decision required exhaustive analysis.

Problems arise when these shortcuts replace thoughtful reasoning instead of supporting it. For example, a team may retain an implementation simply because it exists, not because it meets current requirements. Developers might accept poor practices if the codebase already appears neglected. Architects may select more complex solutions because complexity seems more robust or professional.

These effects can extend far beyond the initial decision. A cognitive bias that starts as an individual preference can influence code reviews, become a team convention, shape architectural decisions, and eventually contribute to technical debt.

The impact therefore goes beyond a single decision. Biases can affect:

• Code quality and maintainability
• Architectural consistency
• Technical debt
• Technology selection
• Resistance to change
• Team standards and engineering culture

The most concerning aspect is that biased decisions rarely seem irrational when made. They often appear reasonable: “this is how we normally do it,” “the code is already messy,” or “we need something more robust.”

Recognizing these patterns does not eliminate them, but it enables engineers and technical leaders to challenge assumptions before they become embedded in the architecture.

This understanding also provides a natural transition to the following sections: status quo bias, the broken windows effect, and complexity bias.

Status Quo Bias: “We’ve Always Done It This Way”

Status quo bias is the tendency to favor the current situation solely because it is established. Samuelson and Zeckhauser showed that people often favor existing options, even when alternatives are available: Status Quo Bias in Decision Making.

In software engineering, this bias can be more harmful than simple resistance to change, as it may keep teams from evaluating decisions against current circumstances.

Software evolves continuously. Requirements shift, languages gain new features, frameworks improve, and teams learn from experience. A decision that was appropriate years ago may no longer be suitable today.

Problems arise when teams assume the current solution is correct by default.

“We’ve always done it this way.”

How Status Quo Bias Impacts Software Engineering

The greater risk is that teams may stop analyzing whether existing decisions still fit the current context, not just that they avoid change.

For example, a Java team may continue using XML configuration simply because it was the original convention, even when annotations or programmatic configuration would better suit parts of the system today.

The problem is not XML itself. XML may still be the right choice. The issue arises when the reasoning is: we used XML before, so we use XML now. This differs from evaluating current requirements, available language and framework capabilities, trade-offs, and then selecting the most appropriate configuration strategy. The same pattern can appear almost anywhere:

• “We always store this in the session.”
• “We always use inheritance here.”
• “We always create a microservice for this.”
• “We don’t use that newer Java feature.”
• “This framework has always worked for us.”

Each of these statements may reflect a valid decision, but none alone provides sufficient technical justification.

The broader risk is that architecture may reflect outdated constraints rather than current needs. Teams may overlook new language features, framework improvements, better APIs, production lessons, infrastructure changes, or architectural alternatives unavailable when the original decision was made.

Over time, the codebase may remain internally consistent but become increasingly disconnected from its surrounding ecosystem. Research on software architecture decision-making shows these choices are not purely rational and can be influenced by bounded rationality and cognitive biases: Decision Making in Software Architecture.

How to Handle Status Quo Bias in a Team

The goal is not to challenge every existing decision or adopt every new technology. Consistency, migration cost, operational risk, and familiarity are all valid engineering concerns.

The key is to ensure that history informs the decision, but does not determine it. A simple question can help:

If we were making this decision today, with our current requirements and tools, would we make the same choice?

This separates two different questions:

1. What is the best design for the current context?
2. Is changing the existing design worth the cost?

Those are not the same problem.

Another useful technique is to make evaluation criteria explicit. Compare the current approach and alternatives using the same dimensions: maintainability, complexity, operational risk, migration cost, framework support, and long-term evolution.

This approach creates a fairer discussion, as the current solution no longer receives an automatic advantage simply because it exists.

Naming the Bias Can Move the Discussion Forward

One effective leadership technique is to name what may be happening.

Instead of saying:

“You are resisting change.”

A staff engineer, architect, or manager can ask:

“Could status quo bias be influencing this decision?”

This shifts the discussion from evaluating individuals to evaluating the decision-making process.

Someone may then realize:

“I prefer this solution because I know it well, not because we compared the alternatives.”

That distinction matters.

Experience says:

“We tried this before, and here are the trade-offs we learned.”

Inertia says:

“We do this because we have always done it.”

Effective technical leadership involves helping teams recognize this distinction.

The goal is not modernization for its own sake, nor is newer automatically better. The aim is to ensure architecture evolves with the context, rather than remaining unchanged simply because the current solution is familiar.

Complexity Bias: “It Can’t Be That Simple”

Complexity bias is the tendency to trust a complicated solution more because it appears more complete, sophisticated, or robust.

Simple solutions can feel uncomfortable, especially for important problems, leading us to expect equally complex architectures. Research on causal reasoning shows that people often view complexity as a sign that an explanation fits the evidence, even though they prefer simplicity in other contexts. See Simplicity and Complexity Preferences in Causal Explanation (ScienceDirect). 

In software engineering, this bias often leads to overengineering.

How Complexity Bias Impacts Software Engineering

The main problem is not complexity itself. Some systems are legitimately complex.

The real issue is unnecessary complexity, as each abstraction, service, dependency, process, and architectural layer adds risk.

Additional components increase the effort required to understand, integrate, test, deploy, monitor, and modify the system. Solutions meant to improve safety can instead expand the potential for failure and raise the cost of future changes.

Simple requirements can accumulate queues, events, retries, services, orchestration, and frameworks, making the architecture seem more robust even when these additions are not justified.

Forbes identifies over-engineering solutions as one of the bad habits technology leaders want developers to avoid, noting that developers sometimes solve problems that don't exist or add complexity before fully understanding the problem (Forbes). 

Complexity bias also influences organizational practices. Teams may add approval stages, meetings, documents, and processes because increased control feels safer. Eventually, even agility suffers. Teams may become attached to processes without evaluating whether they still support effective software delivery.

Just Enough Architecture

George Fairbanks’ concept of Just Enough Software Architecture offers a useful counterpoint.

His risk-driven approach suggests that architectural effort should match the actual risk of failure. When risk is low, extensive design can be wasteful. When risk is high, more deliberate design is warranted (George Fairbanks). 

This gives us a better question than:

“How can we make this architecture more robust?”

Ask instead:

“What risks are we trying to mitigate, and how much architecture do those risks justify?”

That changes the discussion significantly.

An extra service may be justified by isolation requirements. Asynchronous communication may be justified by availability or throughput. Regulation may require additional governance.

However, you should always justify complexity. Fairbanks summarizes the principle well: architectural effort should match the risk of failure (George Fairbanks). 

How to Handle Complexity Bias in a Team

A useful starting question is:

What is the simplest solution that satisfies the requirements and mitigates the risks we actually have?

Technical leaders can then challenge complexity with concrete questions:

What risk does this abstraction reduce?
What requirement needs another service?
What would happen if we did not introduce this complexity yet?

Naming the bias can also help:

“Are we adding this because the problem requires it, or because the simpler solution feels too simple?”

The goal is not simplicity at any cost. Underengineering poses risks similar to overengineering.

The goal is just enough architecture: introduce the complexity needed to manage real risks, but no more than the problem justifies.

Broken Windows: When the Environment Lowers the Standard

Unlike status quo or complexity bias, Broken Windows Theory is not a cognitive bias. Instead, it represents a risk: visible disorder can influence future behavior and gradually redefine what is considered acceptable.

Although the concept originated outside software engineering, researchers have applied it to code quality for decades. Recently, researchers examined whether this effect occurs in software systems. A 2024 study in Empirical Software Engineering found that developers working in systems with higher technical debt were more likely to introduce additional debt, such as poor variable names, duplicated behavior, and other issues detected by static analysis (Springer Link). 

How Broken Windows Impact Software Engineering

A neglected codebase sends signals.

When engineers repeatedly encounter duplicated code, weak tests, inconsistent naming, abandoned abstractions, or ignored warnings, the implicit message can become:

“This level of quality is acceptable here.”

That can change behavior.

Rather than considering how the code should ideally be structured, developers start adapting to their environment:

“This module is already messy.”

“Nobody tests this part anyway.”

“There are already dozens of warnings.”

“One more shortcut will not make a difference.”

The risk is cumulative. While a single compromise may seem minor, repeated compromises can gradually lower the entire system's engineering standards.

The 2024 controlled experiment is notable because it provides direct evidence of this effect. Developers working on systems with higher technical debt were more likely to introduce new debt (Springer Link). 

A second 2024 study examining code history also found that existing code quality can influence the quality of subsequent changes, though the effect varies by quality characteristic (arXiv). 

The Risk Goes Beyond Code

Broken windows can also appear in engineering culture. If architectural rules are routinely ignored, pull requests are poorly reviewed, failing tests are tolerated, or technical debt is continually postponed, developers learn what the organization truly values.

Written standards may say one thing, while the environment says another. That distinction matters because engineering culture is shaped not only by what leaders say, but also by what teams repeatedly observe.

A codebase can therefore create its own feedback loop: Poor quality normalizes lower standards. These changes create additional visible disorder, which further reduces expectations.

How to Handle It in the Team

The goal isn't to create a perfectly clean system, as that can lead to overengineering. Instead, teams should prevent visible problems from becoming the accepted baseline. Small actions matter:

• Fix obvious problems when touching nearby code
• Address warnings and failing tests promptly, preventing them from becoming permanent background noise
• Set a minimum quality standard for new changes
• Make technical debt visible rather than silently normalizing it

Technical leaders can also name the pattern directly:

“Are we accepting this because it is genuinely the right trade-off, or because the surrounding code has already lowered our expectations?”

This question helps distinguish between pragmatic technical debt and simple degradation.

The objective isn't perfection, but preventing the environment from silently teaching the team that quality no longer matters.

A useful principle is:

Every codebase teaches developers how it expects to be treated.

Once poor quality becomes the norm, reversing that expectation becomes much more difficult.