It's easy to talk about software when everything works.
The real test starts when something doesn't.
A server goes down.
An API stops responding.
A payment fails.
A database connection disappears.
A user enters something unexpected.
A deployment introduces a bug.
The question isn't whether these things can happen.
They can.
The question is what your software does when they do.
Failure is normal
Software systems depend on other systems.
Networks fail.
Services become unavailable.
People make mistakes.
Hardware has problems.
Third-party APIs change.
No system can eliminate all failure.
Trying to build software that never fails is unrealistic.
Building software that handles failure properly is realistic.
What happens when something fails?
Consider a simple example.
A customer submits an important request.
The system tries to send it to another service.
That service is unavailable.
What happens?
Does the customer see an error?
Is the request saved?
Will the system retry?
Does someone get notified?
Can the team see what happened?
Can the operation be safely performed again?
These questions are part of the design.
They shouldn't be discovered during an incident.
Error messages matter
Good error handling isn't just for developers.
Users need to know what happened.
Compare:
“Error 500.”
with:
“We couldn't complete your request right now. Your information has been saved and we'll try again.”
The second message doesn't make the failure disappear.
But it makes the situation understandable.
Recovery matters as much as prevention
Teams often spend a lot of time trying to prevent failures.
That's important.
But recovery deserves the same attention.
Ask:
How do we detect the failure?
How quickly do we know?
Can we recover automatically?
Can we retry safely?
What data might be lost?
Can we restore the system?
Who needs to be informed?
A system that fails occasionally but recovers predictably can be more trustworthy than one that usually works perfectly but becomes chaotic when something goes wrong.
Reliability creates confidence
People trust software when they understand what to expect.
If something fails, the behaviour is predictable.
If something is unavailable, they know what happens next.
If data needs to be retried, the system handles it correctly.
If an incident occurs, the team can investigate it.
That's reliability.
It's not just uptime.
It's confidence in the system's behaviour.
Build for the bad day
A useful question during software design is:
“What happens when this doesn't work?”
Ask it for important workflows.
Ask it for integrations.
Ask it for payments.
Ask it for data.
Ask it for deployments.
The answers may not always be complicated.
But having the answers before something goes wrong is one of the differences between software that merely works and software that can be trusted.