Edge Cases & Assumptions

Every plan, every system, and every solution is built on assumptions. Things you believe to be true but have not explicitly verified. Edge cases are the unusual situations that fall outside the "normal" path — the scenarios where those assumptions break down and things go wrong.

Thinking about edge cases and surfacing assumptions is how you build things that work in the real world, not just in ideal conditions.

What Is an Edge Case?

An edge case is a situation that occurs at the extreme boundary of expected conditions. It is not the typical scenario — it is the unusual one that still needs to be handled.

Planning a Party

You are planning an outdoor birthday party for 30 people.

Normal scenario: 30 people show up, the weather is nice, the caterer arrives on time, and everyone has a great time.

Edge cases:

What if nobody shows up?
What if 50 people show up (guests bring friends)?
What if it rains?
What if the caterer cancels last minute?
What if a guest has a severe food allergy you didn't know about?
What if the power goes out (no music, no lights)?
What if a child gets hurt on the property?

None of these are the expected scenario. But each one is possible, and not having a plan for any of them could ruin the event.

You do not need to plan for every conceivable edge case — just the ones that are likely enough or severe enough to warrant preparation.

A Simple Task: Dividing Pizza

Even something as simple as splitting a pizza has edge cases:

Normal: 8 slices, 4 people, 2 slices each.

Edge cases:
  - What if there are 0 people? (Who gets the pizza?)
  - What if there are 3 people? (8 doesn't divide evenly by 3)
  - What if someone wants no pizza? (Do they still count?)
  - What if someone is vegan and the pizza has cheese?
  - What if there are more people than slices?

These seem trivial, but in software, the equivalent of "dividing by zero people" causes systems to crash.

What Is an Assumption?

An assumption is something you treat as true without verifying it. Assumptions are necessary — you cannot verify everything — but unexamined assumptions are dangerous.

A Moving Day Example

You plan to move apartments next Saturday:

Assumptions you might not realize you're making:
  - The new apartment will be ready on time
  - The moving truck will be available
  - The elevator in the building will work
  - Your friends who promised to help will actually show up
  - Nothing in your current apartment is too large for the new doorways
  - The weather will allow loading and unloading
  - Your lease start date and end date overlap (no gap without housing)

Each of these is something you assume will be fine. Most of the time, they are fine. But when one breaks, the whole plan can collapse.

The value of surfacing assumptions is not to worry about everything — it is to identify which assumptions are risky and need a backup plan.

The Relationship Between Edge Cases & Assumptions

Every edge case is a situation where an assumption fails:

Assumption: "All guests will RSVP."
Edge case:  People show up who didn't RSVP.

Assumption: "Users will enter their email correctly."
Edge case:  A user enters "john@" with no domain.

Assumption: "The network is always available."
Edge case:  The internet goes down.

Assumption: "Dates are always in the same format."
Edge case:  European dates (DD/MM) mixed with American dates (MM/DD).

Finding edge cases and finding hidden assumptions are two sides of the same coin. When you ask "what could go wrong?" you discover assumptions. When you list your assumptions, you discover edge cases.

Everyday Edge Cases

Shopping with a List

Assumption: The store has everything on my list.
Edge case:  An item is out of stock. Do I substitute? Skip it? Go to
            another store?

Assumption: Prices are as I remember them.
Edge case:  An item costs twice what I expected. Does my budget still
            work?

Assumption: I have enough bags for everything.
Edge case:  I bought more than expected and cannot carry it all.

Following a Recipe

Assumption: I have all the ingredients.
Edge case:  I'm out of one ingredient halfway through cooking.

Assumption: My oven temperature is accurate.
Edge case:  The oven runs 25 degrees hot, and the dish burns.

Assumption: "Medium onion" means the same size to everyone.
Edge case:  My "medium" onion is someone else's "large."

Catching a Flight

Assumption: Traffic to the airport will be normal.
Edge case:  Major accident causes a 90-minute delay.

Assumption: The flight will be on time.
Edge case:  The flight is cancelled. What's the backup plan?

Assumption: My passport is not expired.
Edge case:  You realize at the airport that it expired last month.

Edge Cases in Technology

Software systems encounter edge cases constantly, and unlike a dinner party host, they cannot improvise. They must have explicit instructions for every situation.

Null & Empty Inputs

Expected: A function receives a customer's name -> "Maria Santos"
Edge cases:
  - Name is empty: ""
  - Name is missing entirely (null)
  - Name contains only spaces: "   "
  - Name contains numbers: "J0hn D03"
  - Name is extremely long: 10,000 characters

Empty Lists

Expected: Calculate the average of a list of numbers -> [85, 90, 78, 92]
Edge cases:
  - Empty list: [] (what is the average of nothing?)
  - One item: [85] (average is itself, but did you handle this?)
  - All same values: [90, 90, 90, 90]
  - Negative numbers: [-5, 10, -3]
  - Extremely large numbers that might overflow

Concurrent Access

Expected: One person edits a document at a time.
Edge case: Two people edit the same document at the same time.
  - Whose changes win?
  - Are changes merged? How?
  - What if they edit the same paragraph?

Expected: One customer buys the last item in stock.
Edge case: Two customers click "buy" at the exact same moment.
  - Do both orders go through?
  - Does one fail? Which one?
  - Is the customer who fails told immediately?

Timezone Issues

Expected: A meeting is scheduled for 3 PM.
Edge cases:
  - 3 PM in whose timezone? The organizer's? The attendee's?
  - What if participants span 12 timezones?
  - What about daylight saving time changes?
  - A meeting scheduled for 2:30 AM on a day clocks spring forward —
    that time does not exist.
  - What about countries that do not observe daylight saving time?

Timezone bugs are so common and so subtle that they have their own category of horror stories in software engineering.

How to Find Edge Cases

Think about boundaries

What happens at the minimum? The maximum? Just above or below a threshold?

Think about absence

What if there is nothing? No items, no users, no data, no network, no time.

Think about excess

What if there is too much? Too many items, too many users, too much data.

Think about timing

What if things happen out of order? What if two things happen at the same time? What if something takes much longer than expected?

Think about bad input

What if the input is wrong? Missing? Malformed? In the wrong format? In a different language?

Ask "what if" relentlessly

"What if the user does X?"
"What if the system is under heavy load?"
"What if this external service is down?"
"What if the data has unexpected values?"
"What if the clock is wrong?"

Edge cases are unusual situations at the boundaries of expected conditions. They are where plans and systems most often fail.
Assumptions are things you believe to be true without verification. Hidden assumptions are the source of most edge cases.
In everyday life, edge cases appear in party planning, travel, shopping, and any activity that depends on things going as expected.
In technology, common edge cases involve null inputs, empty lists, concurrent access, timezone issues, and boundary values.
Find edge cases by thinking about boundaries, absence, excess, timing, and bad input.
Surface your assumptions, write them down, and decide which ones need backup plans. The cost of discovering an edge case during planning is far less than discovering it in production.