The First Question I Ask Before Trusting Any System or Codebase

It’s Not “Does It Have Tests?” or “What’s the Uptime?” — It’s Something Simpler and More Revealing

I’ve inherited three production systems I didn’t build. Each time, there’s a period of calibration — figuring out how much to trust the system, where the edges are, what it gets wrong under which conditions. This calibration is usually done badly, which is why inherited systems so often go sideways within six months of a transition.

The calibration I’ve settled on starts with one question. Not “what’s the test coverage?” Not “what does the monitoring look like?” Not “how often does it go down?”

The question is: how does this system fail?

Not whether it fails. Everything fails. The question is about the character of the failure — and the answer tells you almost everything about whether the people who built it understood it.

What the Answer Reveals

Systems fail in one of two ways: noisily or silently.

Noisy failure is the kind you can’t ignore. Exceptions propagate. Alerts fire. The service returns 500s instead of pretending everything is fine. Engineers get paged. Data stops flowing in a way that’s immediately visible.

Silent failure is the kind you discover weeks later when someone notices that numbers don’t add up, or a user reports behavior that shouldn’t be possible, or you trace a bug back to a function that’s been eating exceptions and returning None for three months.

AI-generated image (prompt by Bhavyansh)

A system that fails noisily is a system you can trust — not because it won’t fail, but because when it does, you’ll know. A system that fails silently is a system you can’t trust, because its “working” state and its “failing” state look identical from the outside.

The first question is how it fails because that answer tells you what kind of trust is warranted.

The First Test I Run

When I inherit a system, I do something that sounds destructive but is actually diagnostic: I look for the most likely failure mode and try to trigger it in a non-production environment.

For a system that reads from an external API, I point it at a dead endpoint. For a system that writes to a database, I give it a schema mismatch. For a queue consumer, I feed it a malformed message.

Then I watch. Does the system surface the failure immediately and loudly? Does it log with context and stop? Or does it absorb the failure and keep running — returning empty responses, incrementing processed-message counters, looking operationally normal while silently doing nothing useful?

Systems that were built by people who understood them fail the first way. Systems that were built under deadline pressure to appear working fail the second way.

# A system that fails noisily — you can trust this
def consume_message(raw: bytes) -> None:
    event = parse_event(raw)  # raises ParseError on bad input
    result = process(event)   # raises ProcessingError on failure
    ack()                     # only reached on success

# A system that fails silently - you cannot
def consume_message(raw: bytes) -> None:
    try:
        event = parse_event(raw)
        result = process(event)
        ack()
    except Exception:
        ack()  # acks even on failure - message disappears quietly

The second version has higher “success” metrics. Everything gets acked. The counter keeps climbing. The dashboard looks healthy. The data is corrupted.

Why This Question, Not the Others

Test coverage is a lagging indicator of past diligence. It tells you how thoroughly the person who wrote the code thought it should be tested, which may or may not reflect the actual failure surface.

Uptime tells you about historical availability under historical conditions. It doesn’t tell you what happens under novel failure modes — which are the conditions that actually matter when you’re debugging at 2 AM.

Documentation tells you what the system was intended to do. The gap between intent and implementation is where failures live.

“How does this system fail?” bypasses all of that. It’s asking about behavior under adversity, which is where trust is actually established or broken. A system that behaves predictably when things go wrong is trustworthy. A system that behaves coherently only when things go right is a liability dressed up as an asset.

AI-generated image (prompt by Bhavyansh)

The Secondary Questions

Once I have a read on failure character, two follow-up questions fill in the rest of the picture.

Who knows when it fails?

A system can fail loudly and still be dangerous if the right people aren’t notified. Loud failure that goes to a log file nobody reads is functionally silent. Loud failure that pages an on-call engineer at 3 AM is genuinely loud. I look for the path from failure event to human awareness and evaluate whether it’s short enough to matter.

What fails independently?

Coupling is the other dimension. If one component fails and takes three others with it — or if a failure in a non-critical path degrades the critical one — the system’s failure surface is larger than any single component makes obvious. A well-designed system has failures that stay bounded: the notification system going down doesn’t affect invoicing, the report generator timing out doesn’t block user auth.

# Failure that stays bounded — what you want
async def generate_report(user_id: str) -> None:
    # Report generation is isolated; timeout only affects reports
    async with timeout(30):
        await _generate(user_id)
# Failure that spreads - what you don't
def process_request(user_id: str):
    report = generate_report(user_id)  # Hangs here, blocks everything
    return build_response(user_id, report)

The second pattern means a slow report generator degrades every user request. One component’s failure becomes the system’s failure. That’s a system that fails in ways you can’t predict from its surface behavior.

Applying This to Your Own Systems

The question isn’t just useful for inherited code. It’s the most productive thing I know to ask about a system I’ve built myself — especially after it’s been running for a few months and the initial confidence has started to wear off.

I try to do a failure-mode review roughly every quarter on systems I own. Not a full audit, just the question: if this component fails right now, in what way will I find out?

For each critical path, I trace the failure propagation. Does it surface? How quickly? To whom? What state does the system end up in — recoverable, or corrupted?

The answers are often uncomfortable. You build systems thinking about the happy path. The failure path is usually less considered than you’d like. Doing this review makes you specific about the gaps rather than generally uneasy about them — and specific problems are fixable in ways that general unease isn’t.

SLAs and uptime percentages dominate how organizations evaluate system reliability. Five nines. Four nines. The number of minutes of downtime per year. These are the metrics that appear in vendor contracts and engineering OKRs.

They’re almost useless as measures of trustworthiness.

A system can have 99.99% uptime and be completely untrustworthy if its 0.01% failure mode silently corrupts data that nobody discovers for three months. A system with 99.5% uptime that fails noisily, recovers automatically, and alerts on-call in two minutes is far more trustworthy than the alternative.

Uptime measures availability. Trustworthiness is a different property — it’s about whether the system’s state is knowable, whether failures are detectable, whether what the dashboard shows reflects what’s actually happening.

I’ve trusted systems with mediocre uptime numbers and been right to. I’ve distrusted systems with excellent ones and been right about that too. The uptime number has never been the right signal.

The right signal is: when this thing breaks, will you know?

AI-generated image (prompt by Bhavyansh)

Making the Question Useful

The next time you inherit a system, join a team with an existing codebase, or do a review of something you own, start here: pick the most likely failure mode and trace what happens.

Does the system surface it immediately? Does it log with enough context to diagnose remotely? Does it stop doing the wrong thing, or keep going?

The answer to those questions is more informative about the system’s quality than anything else you could examine in the same amount of time. It’s the question that tells you whether the people who built it were thinking about operation, not just implementation — whether they built something that would tell them when it was wrong, or something that would look right while being broken.

That’s the difference between a system you can trust and a system you have to watch constantly.

And in production, at scale, that difference is everything.

What’s the most critical component in your current system — and if it failed right now, would you know within five minutes?

Let’s Connect!

If you’re new to my content, I’m Bhavyansh Yadav — a software engineer sharing practical lessons from building and breaking production systems.

I write consistently on Medium, and if you want deeper dives, frameworks, and actionable insights delivered to your inbox every Wednesday, join my newsletter:

**Subscribe to my Substack here**

Thanks for reading!