1.7 Engineering standards and exceptions¶

Overview and motivation¶

An engineering standard is a documented, agreed rule about how work is done. For example, "all services must expose a health-check endpoint," or "all public web pages must meet WCAG (Web Content Accessibility Guidelines) 2.2 level AA." A standard is not a suggestion, and not a mere convention. It is a commitment the organization holds itself to, ideally one you can check. This chapter is about the full lifecycle of standards, how a large organization authors, publishes, adopts, enforces, and evolves them, and, just as importantly, how it handles the cases that legitimately fall outside them through a governed exceptions process (also called a waiver process): a documented, time-boxed permission to deviate from a standard for a stated reason.

The motivation is that at scale, informal norms stop working. When five engineers share one room, "how we do things here" travels by conversation and osmosis. When five thousand engineers span dozens of teams, three time zones, and a decade of staff turnover, that tacit knowledge fragments into hundreds of incompatible local habits. Standards are how you write down your hard-won lessons once, so every team inherits them instead of relearning each one through its own outage. They reduce cognitive load, make code reviews about substance rather than style, let people move between teams, and give auditors and regulators something concrete to assess.

But standards carry a failure mode of their own: rigidity. A standard that admits no exceptions will, sooner or later, block legitimate work: a spike, a vendor constraint, a genuinely novel case the authors never imagined. Teams then either grind to a halt or, worse, quietly ignore the standard, which corrodes the credibility of every standard. The remedy is the old aphorism "the exception proves the rule." A visible, principled exceptions process is what keeps standards both credible and humane. This chapter builds on decision-making and governance (chapter 1.5) and decision records (chapter 1.6), and feeds directly into coding standards and style (chapter 2.1), checklists (chapter 12.2), and templates (chapter 12.3).

Key principles¶

• A standard states an outcome, and gives a reason. Rule plus rationale; without the why, people cannot judge when it truly applies.
• If it can't be checked, it isn't a standard yet. Prefer testable statements over aspirations.
• Standards are living documents. They are versioned, owned, dated, and revised, not carved in stone and abandoned.
• Automate enforcement where you can; reserve human review for judgment. Machines check the mechanical; people check the meaningful.
• Deviations are expected, not shameful, but they must be visible. An honest waiver beats silent non-compliance every time.
• Time-box every exception. A permanent exception is a defect in the standard; surface it and fix the standard.
• Words and examples over jargon and mandates. People follow standards they understand and can copy from.

Recommendations¶

Write standards that are clear, testable, and justified¶

A good standard is a short, self-contained document with a predictable shape so readers know where to look. Adopt one standard template (chapter 12.3) and use it everywhere. Essential sections include:

• Title and identifier: a stable name and reference number for citation.
• Status: draft, active, superseded, or retired, with a date.
• The rule: stated as an outcome, plainly and unambiguously ("must," "should," "may," used deliberately, per the RFC 2119 conventions for requirement keywords).
• Rationale: why this rule exists; the cost or risk it prevents.
• Examples: a compliant example and a non-compliant one; concrete beats abstract.
• How it is checked: the automated test, linter rule, or review step that verifies it.
• Owner and review date: who maintains it and when it is next revisited.

The rationale and the "how it is checked" fields are what separate a real standard from a wish. If you cannot say why a rule exists, question whether it should. If you cannot say how compliance is verified, the rule will be applied inconsistently and resented.

Pair each standard with a good-practice checklist¶

Standards define the destination. A good-practice checklist, a short, ordered list of concrete steps or items to confirm, helps people get there and lets them self-verify before review. Public-sector engineering handbooks use this pattern heavily. NHS Wales and Digital Health and Care Wales (DHCW) publish engineering standards with practical checklists, and the UK Government Digital Service (GDS) pairs its Service Standard and Technology Code of Practice with the Service Manual's actionable guidance. The checklist is the standard made usable: "Have you added an accessibility audit? Have you tested with a screen reader? Have you covered keyboard-only navigation?" See chapter 12.2 for the checklist pattern in full.

Publish standards where people already work, and keep them discoverable¶

Store standards in version control (a source repository) as Markdown, rendered to a searchable internal site, so they get history, review through pull requests, and diffs for free, the same argument as for decision records (chapter 1.6). One catalog, one template, one search box. Surfacing matters as much as storage. Link the relevant standard from the pull-request template, the linter's error message, and the service's scaffolding, so the right rule appears at the moment of the work rather than in a folder no one visits.

Enforce through automation first, human review second¶

There are two ways to enforce a standard, and mature organizations use both deliberately:

• Automated enforcement: linters, formatters, static analysis, policy-as-code (for example, Open Policy Agent (OPA)), continuous integration (CI) gates, and architecture fitness functions (automated tests that assert a design property still holds). Automation is consistent, tireless, immediate, and unarguable, which makes it ideal for the mechanical majority of standards (formatting, naming, dependency rules, required metadata).
• Human review: code review, architecture review boards, and security review, reserved for what machines cannot judge: whether an abstraction is sound, whether a trade-off is wise, whether a standard's intent is met even when its letter is awkward.

The rule of thumb: automate the checkable, and spend scarce human attention on judgment. Every standard you can move from review to CI frees reviewers to do the thinking only they can do.

Govern deviations with a documented exceptions/waiver process¶

No standard fits every case, so design the escape hatch on purpose. A good exceptions process specifies:

• Who can grant a waiver: a named, accountable authority proportionate to the risk (a tech lead for a low-stakes style deviation; an architecture or security board for a security-control waiver). This ties directly to the governance model of chapter 1.5.
• What must be recorded: the standard being deviated from, the specific reason, the scope, the compensating controls or mitigations, and the risk accepted. Capture this as a decision record (chapter 1.6) so the rationale is preserved.
• A mandatory expiry: every waiver is time-boxed with an explicit end date. This is the single most important rule: it prevents a temporary exception from silently becoming permanent policy.
• Periodic review: an owner reviews open waivers on a cadence and either renews them with fresh justification, closes them when the work complies, or, if the same exception keeps recurring, treats that as evidence the standard itself is wrong and revises it.

This last point is the heart of "the exception proves the rule." A steady stream of waivers against one standard is not a failure of discipline. It is data. It tells you the standard is miscalibrated, and the fix is to evolve the standard, not to keep granting exceptions.

Treat standards as living documents with clear ownership¶

Give every standard an owner (a role, not just a person) accountable for keeping it current, and a review cadence (at least annually). Provide a lightweight path for anyone to propose a change through a pull request or an RFC (request for comments), a written proposal circulated for feedback before adoption. Version standards, deprecate them explicitly, and announce changes. A standards catalog that is never revised rots into folklore that people cite selectively and trust little.

Trade-offs: pros and cons¶

The central tension is consistency versus flexibility. A standard exists to remove variation; an exceptions process exists to admit the variation that is genuinely warranted. Lean too far toward rigidity and people route around your standards. Lean too far toward laxity and the standards mean nothing. The exceptions process is the pressure valve that lets you hold a firm line and stay honest about reality.

Examples¶

Startup. A seven-person startup keeps exactly three written standards (a shared formatter config, a health-check endpoint requirement, and "all public pages must be keyboard-navigable"), each enforced by a linter or CI check rather than a review meeting. When one engineer needs to ship a throwaway prototype that breaks the health-check rule, there is no waiver board: she leaves a dated TODO in the code and a one-line note in the pull request saying why and when she will fix it. That is a time-boxed exception at startup scale, honest and visible with no process overhead. The three checks pay for themselves by keeping code review about substance instead of style.

Enterprise. A global bank maintains an internal engineering handbook of about forty active standards, each in one template with a rationale, examples, and a linked good-practice checklist. Roughly 70% are enforced automatically: formatting, dependency policy, mandatory service metadata, and security controls encoded as policy-as-code that fails the CI pipeline. A payments team needs to ship on a database that does not yet support a mandated encryption feature. Rather than block the release, they file a waiver naming the standard, the compensating control (application-layer encryption), and a 90-day expiry. The security board grants it and records it. Ninety days later, the review finds the platform now supports the feature natively, and the waiver is closed. The standard held, the work shipped, and the deviation is fully traceable for the next audit.

Government. A national health agency modeled on the DHCW and GDS approach publishes its engineering standards openly, each paired with a checklist teams complete before a service assessment. Accessibility to WCAG 2.2 AA is a hard standard, enforced by an automated audit in CI plus a manual assessment. A legacy clinical system cannot immediately meet one accessibility criterion without risking patient-safety-critical functionality. The team requests a time-boxed exception. A named senior responsible owner grants it, and records the specific criterion, the interim mitigation (an assisted-access phone line), the remediation plan, and a six-month expiry, creating exactly the traceable, reviewable evidence that oversight bodies require (chapters 4.6, 10.4).

Business case: motivations, ROI, and TCO¶

A standard costs the time to write it, automate its check, and maintain it. The return is paid every time the check runs, and every time an engineer does not have to stop and debate a settled question. Standards convert recurring, distributed decision cost into a one-time authoring cost, the same economics as decision records (chapter 1.6), amplified because a standard governs thousands of future instances, not one past choice.

On total cost of ownership (TCO), the full lifetime cost of building, running, and maintaining a system, standards lower the largest line items: onboarding (new hires inherit consistency instead of reverse-engineering it), maintenance (uniform code is cheaper to change), and assurance (audits are cheaper when compliance is machine-checkable and deviations are already documented). The exceptions process protects that ROI from its main threat: standards decaying into ignored folklore. A credible waiver process keeps the standards trusted, and trusted standards are the ones people actually follow. The cost of skipping all this is invisible on any dashboard. It shows up as slow onboarding, inconsistent quality, and audit findings, and it compounds with every new team and every departure.

Anti-patterns and pitfalls¶

• Rules without rationale: a standard nobody understands is a standard nobody can apply correctly or challenge honestly.
• Aspirational, uncheckable standards: "code should be maintainable" is a value, not a standard; it cannot be enforced or contested.
• No exceptions process: forces a false choice between blocking legitimate work and tolerating silent non-compliance.
• Permanent exceptions: waivers with no expiry that quietly become the real, undocumented policy.
• Waivers without records: deviations granted in a hallway or a chat thread, invisible to the next audit and the next engineer.
• Ignoring the signal: granting the same exception repeatedly instead of reading it as proof the standard needs to change.
• Enforcement-by-nagging: relying on reviewers to catch what a linter should, wasting judgment on the mechanical.
• Standards graveyard: a catalog written once, owned by no one, never reviewed, cited selectively, trusted by few.
• Jargon gatekeeping: standards written for their authors rather than their readers, with no examples to copy.

Maturity model¶

• Level 1 (Initial): Standards are tribal knowledge in senior engineers' heads. Enforcement is ad hoc code-review nagging; deviations are invisible; "the way we do it" varies by team and by who reviewed the change.
• Level 2 (Managed): Some standards are written down, in inconsistent formats and scattered locations. Enforcement is mostly manual. Exceptions happen informally, without records or expiry dates.
• Level 3 (Defined): A single catalog, one template, rationale and examples for each standard, and good-practice checklists. Automated enforcement for the mechanical majority. A documented exceptions process with named approvers, recorded rationale, and time-boxed waivers.
• Level 4 (Optimizing): Standards are surfaced at the moment of work and enforced by policy-as-code and fitness functions. Waivers are tracked, reviewed on a cadence, and mined as signal: recurring exceptions drive standards to evolve. Standards, checklists, and waivers are a living system feeding onboarding, delivery, and audit.

Ideas for discussion¶

1. Which of your standards can you state with a testable rule and a clear rationale, and which are really just aspirations?
2. What share of your standards are enforced automatically versus by a reviewer noticing? What would it take to move ten more into CI?
3. Where do deviations happen today, and would you even know? Are they recorded and time-boxed, or silent?
4. Who is allowed to grant a waiver against your most safety- or security-critical standard, and is that authority proportionate to the risk?
5. Look at your most-waived standard. Is it a discipline problem, or is the standard simply wrong?
6. When was each active standard last reviewed, and who owns it? Which have quietly become folklore?

Key takeaways¶

• An engineering standard is a rule stated as an outcome, with a rationale, examples, and a way to check it: if it can't be checked, it isn't a standard yet.
• Pair each standard with a good-practice checklist so people can self-verify, following the public-sector handbook pattern (NHS Wales / DHCW, UK GDS).
• Store standards in version control, keep them living with named owners and review dates, and surface them at the moment of work.
• Automate the checkable with linters, policy-as-code, and fitness functions; reserve human review for judgment.
• Govern deviations with a documented, time-boxed exceptions/waiver process: named approver, recorded rationale, mandatory expiry, periodic review.
• A recurring exception is a signal to fix the standard, not just to keep granting waivers: "the exception proves the rule." See chapters 1.5 (governance), 1.6 (decision records), 2.1 (coding standards), 12.2 (checklists), and 12.3 (templates).

References and further reading¶

• UK Government Digital Service, Government Service Standard, Technology Code of Practice, and GOV.UK Service Manual.
• NHS Digital / NHS England, Service Standard and engineering guidance.
• Digital Health and Care Wales (DHCW) / NHS Wales, published engineering standards and good-practice checklists.
• Scott Bradner, RFC 2119: Key Words for Use in RFCs to Indicate Requirement Levels (IETF, 1997).
• World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG) 2.2.
• Neal Ford, Rebecca Parsons, and Patrick Kua, Building Evolutionary Architectures (fitness functions as automated governance).
• Torin Sandall et al., Open Policy Agent documentation (policy-as-code).
• GitLab, The GitLab Handbook: a public example of living, version-controlled organizational standards.
• Google, Software Engineering at Google (Winters, Manshreck, Wright): standards, readability, and automated enforcement at scale.
• Atul Gawande, The Checklist Manifesto: the case for checklists as professional practice.