Engineers rarely evaluate every option from scratch.

We accumulate defaults.

A database we know well. An architecture that worked in the last project. A library we trust. A pattern we can implement without opening the documentation.

Defaults are useful. They reduce cognitive load and help us move faster.

But a default can quietly become a conclusion before the decision process has even started.

You think you are asking:

Which option fits this problem best?

But the real question becomes:

How can I justify using the option I already prefer?

That is a very different decision.

One way to challenge this is to temporarily remove your preferred option from the table.

Make the decision as if the thing you currently want to use were unavailable.

Start with the problem, not the product

Before removing your default, describe the problem without naming an implementation. Otherwise, you risk replacing one preferred product with another.

For a database decision, write down the data model, consistency and query requirements, expected scale, latency and availability needs, operational constraints, team experience, deployment environment, migration cost, and relevant failure modes.

For an architecture decision, describe the rate of change, team structure, deployment and scaling needs, domain boundaries, regulatory constraints, operational maturity, and tolerance for distributed failure.

For a code-level decision, focus on readability, expected variation, performance sensitivity, testing requirements, ownership, and the likely cost of another abstraction.

You can still weigh these criteria differently. Every engineering decision contains judgment. But when the criteria exist before the conclusion, the choice becomes harder to manipulate.

Pretend your preferred option does not exist

Imagine that you need a vector database.

You have used Qdrant before. You understand its API, filtering model, deployment options, and place in your application architecture. Naturally, it becomes the leading candidate.

Before choosing it, pretend Qdrant does not exist. Would PostgreSQL with pgvector be sufficient? Would Azure AI Search fit better because the application is already heavily integrated with Azure? Would a managed service reduce operational responsibility? Would another vector database offer a feature that matters more for this workload?

Do not merely list the alternatives. Build the strongest case you can for each of them.

The weak version of the reasoning sounds like this:

We need vector search, and Qdrant is good at vector search.

A stronger version makes the conditions visible:

We need filtered vector search for tenant-scoped documents, predictable local development, simple operations, and a migration path if retrieval volume grows. Qdrant fits that well, but pgvector may be enough if we already operate PostgreSQL and the search workload stays modest.

The second version gives you claims that can be tested instead of a product preference that can only be defended.

Defaults shape the questions we ask

Once we prefer an option, our reasoning often changes.

Instead of investigating whether the option fits, we begin collecting evidence that supports it. We notice its strengths, reinterpret its weaknesses as acceptable trade-offs, and ask questions that our preferred option can answer well. We compare alternatives against the parts of the problem where our default is strongest.

This is not unique to engineering. Psychology describes several related tendencies.

Confirmation bias makes us more likely to notice evidence that supports an existing belief. Status quo bias can make the current option disproportionately attractive. The availability heuristic draws us toward ideas and technologies that come to mind easily. Motivated reasoning allows us to construct rational explanations for conclusions we were already inclined to reach.

None of this means engineers are irrational. It means that intelligence does not remove bias. Sometimes it merely makes us better at defending our preferences.

A technically sophisticated justification can still be a justification written after the decision was already made.

Argue against your own architecture

This mental model becomes more valuable as the size of the decision increases.

Suppose your instinct is to build a microservice architecture. Temporarily remove microservices and design the strongest modular monolith you can. Ask how you would isolate domains, enforce boundaries, separate ownership, scale the expensive parts, and preserve the option to extract services later.

Now reverse it. If your default is a monolith, design the system as independently deployable services. Which boundaries would you choose? Which parts need different scaling characteristics? Where would independent deployment provide real organizational or operational value? What failures should be isolated?

You may still choose the monolith or the microservices. But the decision is now based on a more complete model of the problem.

You have tested your preferred architecture against a credible alternative rather than a deliberately weak version of it.

Many technical comparisons are decided by how the alternatives are framed. If microservices are your default, do not compare them with an undisciplined monolith. Compare them with a well-designed modular monolith. If a monolith is your default, do not compare it with a distributed system where every boundary and failure mode has been handled poorly.

The same rule applies at the code level. If you prefer Entity Framework Core, compare it with Dapper used well. If you prefer Dapper, compare it with Entity Framework Core configured and applied competently. If you prefer design patterns, compare them with simple code written by someone who understands change and cohesion. If you prefer avoiding patterns, compare simplicity with the actual complexity likely to emerge over time.

Your preferred option does not get to be compared with the weakest version of its alternatives.

In a team, the exercise works best when nobody is asked to defend their identity or a previous decision. Agree on the criteria first, then assign someone to make the strongest case for each credible option, including one they did not propose. Keep the discussion focused on conditions: What would have to be true for this option to win? The goal is not to defeat an advocate. It is to make the trade-offs explicit enough that the team can change its mind without anyone losing face.

The exercise only works when the alternatives are treated seriously. You are not trying to win a debate against yourself. You are trying to expose assumptions that your preferred solution allows you to ignore.

Familiarity is evidence, but it is not the only evidence

This mental model should not turn familiarity into something suspicious. Knowing a technology well allows the team to implement it faster, diagnose problems more easily, recognize its failure modes, and reuse existing tooling. A familiar solution may be the lowest-risk option even when another looks slightly better on paper.

The problem begins when familiarity is hidden behind supposedly objective reasoning. “We know how to run this reliably” is a valid argument. “This is clearly the best technology” may not be.

Sometimes the honest decision is:

Several options would satisfy the technical requirements. We are choosing this one because the team already understands it and the switching benefit is too small to justify the additional risk.

That is not laziness. It is a trade-off.

Ask what would have to be true

Another way to apply the exercise is to ask:

What would have to be true for the alternative to be the better decision?

What would have to be true for Dapper to be a better fit than Entity Framework Core? Perhaps the application has a small number of stable, performance-sensitive queries and little need for change tracking or complex object mapping. Conversely, Entity Framework Core may be the better fit when the domain changes frequently, most queries are ordinary application queries, and development speed matters more than extracting every possible percentage of database performance.

What would have to be true for microservices to make sense? Perhaps different parts of the system have independent release cycles, clear ownership, distinct scaling requirements, and teams capable of operating distributed systems. A monolith may be the better option when the boundaries are still evolving, the team is small, deployment independence offers little value, and operational simplicity is more important than theoretical autonomy.

The better option is the one whose required conditions most closely match reality.

Use the exercise proportionally

Not every decision requires an architectural review.

You do not need a decision matrix before choosing a collection type or installing a minor development tool.

The effort should match the cost of being wrong.

Use the exercise when a decision is:

  • expensive to reverse
  • likely to shape future architecture
  • difficult to migrate away from
  • operationally significant
  • politically influenced
  • strongly tied to personal preference
  • being justified with words like “obviously,” “always,” or “standard”

The stronger your initial certainty, the more useful the exercise may become. Certainty can come from experience, but it can also come from familiarity, identity, habit, or repeated exposure to the same arguments.

The purpose is not to become permanently uncertain. It is to earn confidence rather than assume it.

A decision should survive the absence of your favorite answer

Good engineering judgment is not the ability to immediately name the correct technology. It is the ability to understand the conditions under which different choices become correct.

Your default may still win.

But the decision is stronger when it survives a process designed to defeat it.

So before making an important technical choice, remove your preferred answer. Pretend it is unavailable. Build the strongest possible case for the alternatives, then bring your default back into the comparison.

You may end up in exactly the same place. But you will understand why you are there.

Sources