Sensible default

A sensible default is a practice that, absent overriding context, should be used when carrying out a certain kind of task — “use version control”, “separate UI from domain logic”, “automate deployment pipelines”. The term (popularized in Thoughtworks by Evan Bottcher, name via James Ross) is a deliberate contrast to “best practice”:

• “Best practice” implies a general presumption of always-do — conversation-stopper framing.
• A sensible default is expected to be reassessed in a new context — a known-good starting point, overridable when circumstances change.

Bottcher’s definition (from the captured bliki post):

A sensible default is what we’d expect you to do, the practices to apply, if there are no hard constraints in the environment. Do these practices, or do better, and be prepared to explain why you’ve chosen some other way.

Three load-bearing clauses: “no hard constraints” (the default applies by default, not absolutely), “or do better” (defaults are a floor, not a ceiling), “be prepared to explain” (deviation is allowed, silence isn’t — the burden of explanation moves with the deviation, not the adoption).

Why this framing fits the garden

• The Golden repo note is literally a list of sensible defaults for a reference repository — structure, git flow, hooks, CI, tests, docs — each with its “when to override” context already implicit in the open questions.
• The min-age cooldown settings in Supply Chain Security are sensible defaults with an explicit override path: 7-day default, per-package exclusion for security fixes, reviewed lockfile diff as the explanation.
• Thoughtworks operationalizes the pattern as a published playbook of defaults + regular reassessment (the Technology Radar is that reassessment made periodic) — the same shape as the garden’s log+review cadence.

The connection to the twelfth agile principle is part of the definition: teams reflect at regular intervals and tune — defaults are meant to drift as the environment changes, and a default nobody has revisited is a default nobody owns.

The playbook (captured)

Thoughtworks operationalizes the concept as a published playbook — 12-page e-book captured as PDF + text. Structure: principles (applied by all practitioners) + practices across nine areas — business analysis, data & AI, experience design, infrastructure, product, project management, quality analysis, security, software development. The four stated payoffs: reduce cognitive load, reduce friction, enhance collaboration, faster onboarding. Origin story: practices spread historically through tribal knowledge in co-located teams; remote work forced the codification. The e-book’s own caveat mirrors Fowler’s bliki: “given a particular situation, some of our sensible defaults might not be the right thing to do.”

Related: Golden repo · Supply Chain Security · Career development (Bottcher/Ross lineage is consulting-world engineering culture)