A pragmatic approach to building software that just works
First, use the system as intended.
Tools are already configured correctly. Frameworks offer reasonable ways to solve problems. Databases are optimized for typical workloads.
Most problems are created by our own hands. Not by bugs, not by load, not by business requirements — but by the desire to make things "interesting" where they need to be "reliable."
Choose the path that makes delivery predictable and operations boring.
By default, use the recommended path of the technology. If the default meets the requirements — the decision is made.
If a framework or technology offers a way to do X, then do X that way.
If non-standard behavior is needed — prefer a thin layer of logic over mature primitives, rather than deep intervention into someone else's internals.
Troubleshooting is not the goal. It often appears as a side effect of unnecessary complexity.
The standard path is usually better documented and observable — making it easier to maintain and diagnose.
Deviation is only acceptable if you can answer: "why is this needed, what will improve, and by how much?"
Any deviation from the default must have an owner: monitoring, alerts, diagnostics, runbook, rollback/replacement plan.
Default Driven Engineering is not a claim that defaults are perfect. It is a way to start with the most predictable option and avoid adding complexity too early.
In real life, defaults do not always fit. The product grows, requirements change, and new limits appear: latency, cost, security, or compliance. Deviations are inevitable — and that’s fine.
The difference is that complexity is not added “because it’s interesting”. Complexity must buy something, and it must have an owner. Otherwise it becomes a source of unique failures and unique fatigue.
Complex solutions and heroic troubleshooting are easy to notice and easy to reward. Simplicity is often invisible — it just works. That is enough.
Default Driven Engineering. Use defaults. Ship. Sleep.