Proximate vs Ultimate: The Bug Is Never Just the Bug

Evolutionary Adaptation and Software Design

I was reading about species adaptation when I stumbled on a concept that wouldn't leave me alone: Proximate and Ultimate Causation. Wikipedia defines it as:

A proximate cause is an event which is closer to (more immediately responsible for) causing some observed result. This exists in contrast to a higher-level ultimate (or distal) cause, which acts less directly through the proximate cause.

Ernst Mayr popularized these concepts in Cause and Effect in Biology (1961). The short version:

Ultimate causation asks why a trait exists at all. The evolutionary reason something is there. Natural selection, adaptation, history.

Proximate causation asks how something works right now. Physiology, genetics, development, immediate environment.

Classic Example: Birdsong in Spring

Question: Why does the bird sing?

• Proximate: Increasing day length triggers hormonal changes; vocal muscles activate.
• Ultimate: Singing attracts mates and defends territory. More singing, more offspring.

Example: Human Hunger

Question: Why do we feel hungry?

• Proximate: Low blood glucose hits the hypothalamus, ghrelin gets released.
• Ultimate: The ancestors who went looking for food when energy dropped are the ones who made it.

Why This Distinction Actually Matters

A classic example of confusing the two::

"Humans have religious beliefs because the temporal lobe produces spiritual experiences."

That's proximate. It explains the mechanism, not the origin. The ultimate question is different: maybe religious belief enhanced group cohesion, and groups that cohered survived better. Two completely different questions wearing the same label.

You see this all the time in evolutionary psychology:

• Proximate: "Men prefer young partners because testosterone influences mate selection."
• Ultimate: "Male ancestors who preferred fertile partners had more offspring."

Neither answer is wrong. They just aren't competing.

Applying This to Software

Bug-Fix Scenario

You get a 500. The stack trace points to a null check missing on customer_number. Unhandled AttributeError. That's proximate and yes, it's the code.

But ask yourself why that code existed: the team was sprinting hard on features, no one owned error handling, and the PR got waved through. That's ultimate. Fix the null check and the next unreviewed PR will introduce a different unhandled edge case. You treated the symptom.

Feature Request

We need a POST /trademark-identifier endpoint because the client requires reverse image search to identify sales related to a particular brand.

• Proximate: The client needs reverse image search for branding identification.
• Ultimate: Our competitor shipped visual search last quarter and we're losing RFQs to them.

The proximate is the ticket. The ultimate is why the ticket exists at all. If you only read the ticket, you might build the minimum. If you understand the pressure, you scope it differently.

Architecture Decision

We're extracting the auth service from the CRM because the monolith is too coupled and deployment takes 20 minutes.

The proximate answer is right there in the sentence. But the ultimate is messier: the company hired three more backend engineers, the PR queue is a graveyard, and features are taking two weeks to ship. Conway's Law isn't just a fun observation here. It's the actual selection pressure. The org outgrew the architecture, and the architecture is fighting back.

The Dangerous Pattern: Mistaking Proximate for Ultimate

In my experience as Software Architect, postmortems and design docs are full of this:

"The microservice split fixed our deployment time issue."
"We decluttered the database by partitioning large tables."

Both statements are probably true. And both are proximate. The deployment was slow because the monolith was coupled; the database was slow because it was bloated. Fine. But neither statement touches why the coupling existed or how the data got that way.

In the deployment case, the ultimate cause is usually this: the team grew faster than the domain was ever modeled. No one drew boundaries early because there was no pressure to, two engineers sharing a codebase don't need bounded contexts. By the time there were ten engineers, the coupling was load-bearing and painful to remove. The microservice split relieved the pain. It did not fix the underlying habit of building without domain boundaries.

In the database case, the ultimate cause is almost always ownership. No team owned the schema. Feature work landed wherever it fit. Partitioning cleans it up, but the next six months of features will re-create the mess if no one changes how data decisions get made.

Fix only the proximate like split the service and partition the database, and in six months you'll be back here. The new architecture will re-develop the same patterns, because the pressure that created the original problem is still active. That's software evolutionary convergence: systems drift toward the shape their environment selects for, regardless of how you restructure them.

The ultimate cause point isn't the coupling. It isn't the team size. It's that no mechanism was ever put in place to maintain domain boundaries as the team grew. Coupling is the symptom. Missing governance is the cause.

A Framework for Teams

When your team is about to implement something, ask two questions out loud:

Before implementation:

• Proximate: What exactly are we changing?
• Ultimate: What pressure is forcing this change? (Competition? Team growth? User feedback? Accumulated debt?)

After the first implementation:

• Proximate: Did it work?
• Ultimate: Is the pressure still there, or did we just treat the symptom?

The microservice deployment example again: time drops, the board is happy. But if the monolith was coupled because the team shared a database and never drew domain boundaries, that coupling pressure is still live. The system will pull itself back together. You bought time, not a solution.

Don't Fall for the "Just a Ticket" Trap

Consider the following scenario: No staging env for a service. Only dev and prod.

• Proximate: No staging env exists.
• Ultimate: The team went from 2 to 8 engineers, and the "ship to prod, test there" workflow that worked fine at 2 people is catastrophically risky at 8. The infrastructure didn't grow with the team.

Build the staging env, it's the right call. But the ultimate cause here isn't a missing environment; it's that no one owns the relationship between team size and process maturity. At 2 engineers, that gap is invisible. At 8, it's a staging env. At 15, it'll be the deployment pipeline. At 25, it'll be the on-call rotation falling apart at 3am.

So yes, build the env. And then name the real ticket: "as we grow, what process reviews do we run to catch the next thing our infrastructure isn't ready for?" That ticket probably doesn't exist. That's the one worth opening.

The ultimate cause point here is the absence of a feedback loop between team size and infrastructure maturity. Every team encounters these gaps. Most just build whatever env is on fire today and call it done. The adaptation is a recurring review — not a one-time build.

A practical technique:

1. Write down the proximate cause. Something short that the room agrees on. If it's large, split it.
2. For each proximate cause, ask "why was that true?" three more times, using the previous answer as the starting point.
3. You'll land on the ultimate cause, or close enough to name it.

This is a rougher version of the Five Whys. What makes it useful here is naming the levels explicitly, proximate versus ultimate, so the team can't pretend the patch is the solution.

Stop at proximate and you shipped a patch. Address both, and you've actually adapted.