Questioning Assumptions

"We need microservices." Why? "Because we're scaling." Are you? "We need Kubernetes." Why? "Because everyone uses it." That is not reasoning. That is repetition. Most technical "requirements" are actually assumptions that nobody questioned — and they persist because questioning them feels risky, slow, or confrontational.

Assumptions Disguised as Requirements

In engineering, assumptions hide inside the language of certainty. They masquerade as requirements, constraints, and best practices. The problem is not that assumptions are wrong — many are perfectly reasonable. The problem is that unchallenged assumptions accumulate, and each one narrows the solution space unnecessarily.

Statement                           Requirement or assumption?
---                                 ---
"We need 99.99% uptime"            Assumption. Who said? For which
                                     endpoints? What is the cost?
"The API must be RESTful"           Assumption. Based on what analysis?
"We need to support IE11"           Assumption. Check the analytics.
"Tests must run before merge"       Requirement. (This one is real.)
"We need a microservice for this"   Assumption. What problem does it solve?
"The migration must have zero       Assumption. Can we tolerate 5 minutes
 downtime"                           of read-only mode instead?

The distinction matters because requirements constrain the solution appropriately, while unchallenged assumptions constrain it unnecessarily. Every false requirement you accept eliminates solutions that might be simpler, cheaper, or better.

The Microservices Example

The microservices trend is one of the most expensive examples of assumption-driven architecture in recent engineering history. The reasoning chain typically goes:

"We need microservices."
  Why?
"Because we need to scale."
  What specifically needs to scale?
"The whole system."
  Does the whole system have the same scaling characteristics?
"Well, no. The image processing is CPU-bound and the API is IO-bound."
  Could you scale those independently without a full microservice split?
"I... suppose we could extract just the image processing."
  So you need one extraction, not a microservice architecture?
"Maybe."

What started as "we need microservices" — an assumption borrowed from conference talks and blog posts written by engineers at companies 100x your size — collapses into "we need to extract one compute-heavy module." The difference in implementation cost is measured in months or years.

The Kubernetes Example

Kubernetes follows a similar pattern:

"We need Kubernetes."
  Why?
"Because we need container orchestration."
  Why?
"Because we have multiple services."
  How many?
"Three."
  Do three services need a container orchestrator?
"Well, we want auto-scaling."
  Your cloud provider has auto-scaling for VMs and managed containers.
"But Kubernetes is the industry standard."
  For companies with dozens or hundreds of services. You have three.
"..."

The assumption — "Kubernetes is necessary" — came from analogy with companies that have very different problems. Questioning it reveals that a simpler solution exists. The three services run fine on a managed container platform with a fraction of the operational overhead.

The 5 Whys Applied to Technical Assumptions

The 5 Whys technique, borrowed from Toyota's production system, is the most practical tool for questioning assumptions. You take a statement and ask "why?" until you reach either a fundamental truth or an assumption that cannot justify itself.

Statement: "We need to rewrite the frontend in React."
Why?
  "Because the current jQuery codebase is unmaintainable."
Why is it unmaintainable?
  "Because there are no components, state is everywhere, and nobody
   understands the event flow."
Why is there no structure?
  "Because we never established patterns — people just added jQuery
   wherever they needed interactivity."
Why not establish patterns in the existing codebase?
  "We could. But the team knows React and not jQuery."
Why does the team not know jQuery?
  "Because we hired for React skills."

Root insight: The "unmaintainable jQuery" problem is partially a
staffing decision. The rewrite may be the right call, but the reason
is "our team can't maintain jQuery" not "jQuery is unmaintainable."
That reframe matters because it changes the risk analysis.

Notice that the 5 Whys did not conclude "don't rewrite." It clarified the actual reason for the rewrite, which changes how you plan and de-risk it.

Categories of Hidden Assumptions

Assumptions in engineering tend to cluster in predictable categories:

Technology Assumptions

"We need a message queue for this."
  Maybe. Or maybe a database table with a status column is enough
  for your 10 events per minute.

"We need a distributed cache."
  Maybe. Or maybe the application's local memory is enough for your
  working set of 200MB.

"We need machine learning for this."
  Maybe. Or maybe a set of hand-written rules covers 95% of cases
  and is debuggable.

Scale Assumptions

"This won't scale."
  To what? 10x current traffic? 100x? 1000x?
  When do you expect to hit that scale?
  What is the cost of solving it then vs now?
  YAGNI applies to scale too.

"We need to handle millions of requests."
  Do you currently get millions of requests?
  If not, when will you? Are you sure?
  Is the cost of designing for millions now worth the risk of
  never reaching millions?

Process Assumptions

"We need to do sprint planning."
  Why? What problem does it solve for your team?
  Is a 2-week cadence the right length?
  Could you plan continuously instead?

"Every PR needs two approvals."
  For every change? A typo fix needs two reviewers?
  What is the actual risk you are mitigating?
  Is there a lighter-weight approach for low-risk changes?

"We need to write a design doc."
  For this feature? Is the problem ambiguous enough to warrant it?
  Or is this a well-understood change where the doc is ceremony?

Business Assumptions

"The customer needs real-time updates."
  Did they say that, or did you assume it?
  Is "within 30 seconds" real enough?
  What is the engineering cost difference between real-time
  and near-real-time?

"We can't change the API — it'll break clients."
  Which clients? How many? Have you asked them?
  Can you version the API instead?
  What is the cost of maintaining the old API forever?

How to Question Without Being Adversarial

Questioning assumptions in a team setting requires social skill. "Why are we doing it that way?" can sound like "that's a stupid approach" if delivered poorly. The goal is collaborative exploration, not interrogation.

Adversarial:   "Why would we use Kubernetes for three services?
                That makes no sense."

Collaborative: "Help me understand — what problem does Kubernetes
                solve that a simpler approach wouldn't? I want to
                make sure we're not over-engineering this."

Adversarial:   "Who decided we need 99.99% uptime? That's absurd."

Collaborative: "I see we're targeting 99.99% uptime. What's the
                business impact of 99.9% instead? That would
                simplify the architecture significantly."

The collaborative versions achieve the same goal — they surface and challenge assumptions — without making anyone defensive. They also produce better results because people are more honest when they do not feel attacked.

The Assumption Audit

For high-stakes decisions like system redesigns, major migrations, or new product architecture, it is worth doing a formal assumption audit. List every assumption the decision rests on, classify each one, and validate the critical ones.

Decision: Migrate from PostgreSQL to DynamoDB

Assumptions:
  1. Our query patterns are key-value. [Validate: check query logs]
  2. We need horizontal scaling. [Validate: check growth projections]
  3. DynamoDB is cheaper at our scale. [Validate: run cost model]
  4. The team can learn DynamoDB quickly. [Validate: ask the team]
  5. Our ORM supports DynamoDB. [Validate: check compatibility]
  6. We don't need complex joins. [CRITICAL: audit all queries]

Result of audit:
  Assumption 6 is false. Three critical reports use multi-table joins.
  Either those reports need redesigning or DynamoDB is the wrong call.

The audit took half a day. It saved months of migration work that would have stalled on assumption 6.

Common Pitfalls

Questioning everything equally — not all assumptions are worth challenging. Focus on the ones that are load-bearing: if this assumption is wrong, does the whole plan collapse?
Questioning without proposing — "Why are we doing X?" is incomplete without "Have we considered Y?" Pure skepticism is exhausting. Constructive questioning proposes alternatives.
Assuming assumptions are wrong — challenging an assumption does not mean it is wrong. Sometimes you question an assumption and discover it is well-founded. That is a good outcome — you now hold the assumption with confidence instead of ignorance.
Stopping at the first why — "Why do we need Kubernetes?" "Because DevOps said so." That is not a root cause. Keep going. Why did DevOps recommend it? What problem were they solving? Is that still the problem?
Confusing consensus with validation — "Everyone agreed on this in the meeting" is not validation. Agreement in a room is social proof, not evidence. The assumption still needs to be checked against reality.

Key Takeaways

Most technical "requirements" are assumptions nobody questioned. Challenge the statement before accepting the constraint.
The 5 Whys is the most practical tool for surfacing hidden assumptions. Keep asking until you reach a fundamental truth or a baseless assertion.
Assumptions cluster in predictable categories: technology, scale, process, and business. Develop the habit of checking each category.
Question collaboratively, not adversarially. The goal is to find the truth together, not to win an argument.
For high-stakes decisions, do a formal assumption audit: list, classify, and validate every assumption the decision rests on.
Sometimes questioning an assumption confirms it. That is valuable — you now hold it with conviction instead of inertia.