Quality by Design
Build quality in from the start; don't inspect it in later.
Overview
Quality is a property of how we design and build, not a gate at the end. Correctness, testability and observability are designed in from the first commit.
Why
A gate at the end catches what it was told to look for. Design catches what nobody thought to look for, and it catches it at the cheapest possible moment. The cost gradient is steep and it runs one way. A misconfiguration caught by a failed deploy costs a rebuild. The same misconfiguration caught by a user has already become someone's bad afternoon, and in some domains it has already become a disclosure. Validation belongs at process start, in aggregate, reporting every problem at once, because a person fixing three problems should learn about all three in one pass.
Standard
Validate at startup, not lazily. Report every problem together rather than stopping at the first. Every check that must pass for a process to start is a check worth re-running while it runs. Startup gates and health checks are one declaration with two consumers, not two lists that drift. Prove function, not construction: a client that was successfully built has demonstrated nothing about whether its credentials work. Where a rule could instead be a structural guarantee, make it structural. A checklist earns its place only by catching the class of failure the code cannot see.
What This Forbids
- Lazy validation of infrastructure, a configuration error that surfaces as a request error
- Reporting the first problem and stopping
- Health checks that verify construction rather than function
- A checklist that only restates what the code already validates
- Treating a guarantee enforced by someone remembering as a guarantee
Examples
- Independent refuse-to-boot gates for transport security, schema currency, storage reachability and configuration validity, so a misconfigured deployment fails at the deploy rather than during a working day.
- Splitting liveness from readiness. Liveness stays dependency-free, because a brief blip would otherwise restart every instance at once. Readiness runs a real query, because a connection pool can hold sockets to an unresponsive server, and it reports unavailable so the load balancer drains the instance instead of feeding it failing requests.
- A go-live checklist scoped deliberately to what the application cannot enforce: confirming in a browser that the session cookie carries its security flags; confirming a content-security policy actually permits the API origin, because a blocked request leaves no trace in the server log and the browser console is the only place it appears; confirming a storage setting no code can assert.
- A readiness check that sends its failure reason to the log rather than the response, because the underlying error text names host, port, database and role, and that endpoint is polled unauthenticated.
Counter Examples
- An unconditional health endpoint that always answered yes, so load balancers kept routing traffic to instances with a dead database.
- A storage health check that verified a client object had been constructed. The client builds happily from completely wrong credentials and fails on first use, so the check proved nothing and had to become a real round trip.
- Build identity served anonymously next to a permission-gated endpoint. It tells a stranger which published advisories a host is exposed to, and leaving it in the open made the gate beside it decorative.
Lessons Learned
- The cheapest failure is a failed deploy. Every design that converts a configuration error into a request error has traded a rebuild for an incident.
- A test double that documents where it stops being trustworthy is worth more than several that do not.
- Even strong trust between experienced engineers needs procedural guardrails. A change can be individually reasonable at every step and still reach production through the gap where several small skipped steps line up.
- Every guarantee enforced by someone remembering to run it is not enforced. Naming that gap honestly is more useful than claiming coverage.
Learned From
- DentraRefuse-to-boot gates and the liveness/readiness split, written after an unconditional health check kept traffic flowing to instances with a dead database.
- DentraA go-live checklist deliberately scoped to the failures code structurally cannot see, with explicit stop conditions.
- QA processEngineering gates, readiness, pre-development approval and sign-off, as the team-scale form of the same idea, including the incident that showed what happens when several are skipped at once.
Related Principles· 2
Related Documents· 5
Referenced By· 8
Version History
- v0.1.0
Principle established with placeholder content.
- v0.2.0strengthened
Written from real experience. Added startup gates, the liveness/readiness distinction, proving function over construction, and the standard a checklist must meet to be a control rather than theatre.