How to ship software with confidence - The Pillars
The pillars for making releases without feeling like you're gambling with a coin every Friday afternoon.
One of the hardest parts of software engineering is not building software. It is shipping it with confidence.
Because releasing software should not feel like a coin toss, especially not on a Friday at 6 p.m., when everybody is already mentally halfway into the weekend, and the margin for dealing with surprises is much smaller than we would like to admit.
If every release feels risky, the problem is usually not the release itself. The problem is the system behind it.
In today’s email, you will learn the pillars that help you build software in a way that makes shipping safer, calmer, and more predictable.
And I do not mean only coding practices. I mean everything that shapes the Software Development Lifecycle, or SDLC.
At a high level, three things matter:
Housekeeping principles
A system that speaks
Observability that helps you anticipate and react
A good approach is not to attack them one by one from top to bottom. It is better to work across them gradually, improving a bit of each and iterating over time, because that is usually how real systems improve in the real world.
This is where release confidence starts.
Housekeeping principles
Before your system can help others, it has to be able to help itself.
If your systems are not stable, understandable, and maintainable, you will not create real value for your customers, because even if the product looks good from the outside, the internal machinery will keep creating friction, uncertainty, and avoidable risk.
This is where the basics matter more than people like to admit.
1. Make roles clear
If people do not understand their role, ownership disappears.
That is how you end up with a red monitor in production and nobody acting, not because people do not care, but because nobody feels clearly responsible enough to move first.
A team with unclear roles hesitates. It avoids decisions instead of solving problems, and that hesitation becomes part of the system as much as any technical debt.
2. Use a common programming language
If only one person understands a service, you do not have a system you can trust. You have a bottleneck.
Ownership drops, debugging slows down, and the whole service becomes riskier than it needs to be, because every meaningful change or incident ends up depending on the same small number of people.
Software is not only technical. It is social too, and the social side matters more than many teams realize until production starts asking uncomfortable questions.
3. Decouple your applications
The more isolated your system is, the safer it becomes to change, because failures are less likely to spread in unexpected ways, the responsibilities of each module stay clearer, and the whole system can tolerate change without collapsing under its own coupling.
That is why decoupling matters so much.
Inside the application, it means keeping modules properly separated and making sure a failure in one place does not cascade uncontrollably into others. Outside the application, it means avoiding hidden coupling through infrastructure, configuration, or assumptions that nobody wrote down but everybody has been quietly relying on.
A system that speaks
If your system cannot explain what is happening, you are blind in production.
Do you remember the sentence from the Clean Architecture book, “The architecture that speaks“? This is the same idea.
Your logs should make it clear whether a failure comes from
Infrastructure.
External dependency.
Your own service.
If you cannot tell where the problem started, you will waste time blaming the wrong layer, and in production, that kind of confusion is not a minor inconvenience; it is time your users feel directly.
A good system answers questions quickly, and it does so in a way that helps you move, not just stare at the screen:
What failed?
Where did it fail?
Is it internal or external?
Is it isolated or systemic?
If your logs cannot answer that, they are noise.
Anticipate and react with observability
The best moment to detect a problem is before your users do.
Observability is not about having dashboards for the sake of it. It is about designing signals that help you act while there is still room to do something useful.
Early warning signals
These alerts tell you something is drifting before it becomes visible to the customer:
Latency increasing.
Error rates are growing.
Queues are building up.
Resources saturating.
Their value is not panic, but time. They give you time to investigate, time to understand what is changing, and time to act before a small deviation turns into a production incident.
Failure signals
When something is already broken, you need clarity more than anything else.
At that point, the alert should make it obvious what is failing, how bad it is, and what to do next.
This is where runbooks matter, because a good alert without a clear action is incomplete, and a paged engineer without a clear first step is often forced to improvise under pressure, which is exactly what good observability is supposed to reduce.
A runbook should answer:
What does this alert mean?
What likely caused it?
What to check first?
What to do next?
Short. Concrete. Actionable.
In a future issue, I will go deep into something important: How to make releases actually safe.
So far, let’s wrap up for today.
✨ Takeaways
Shipping software at 6 p.m. on a Friday shouldn’t feel like an extreme sport. If you want to move from anxiety to total peace of mind every time you push to production, keep these three golden rules in mind:
Isolate the impact (Decoupling): Design your application so a failure in one module doesn’t bring down the entire system. When you contain errors locally, changing code becomes infinitely safer.
Make your system speak (Clear logs): You are flying blind in production if your logs can’t answer three questions in seconds: what failed, where it failed, and whether the issue is yours or from an external API. Less noise, more context.
Never improvise under pressure (Runbooks): An alert without a clear action plan is useless. Every critical page must include a short, direct document mapping out the first three steps to fix the issue. You defeat panic with clear instructions.
From here, I would like to hear from you about your tales deploying in Production and what you do in order to get confident for each release.
Best,
Marcos.