Stare Decisis in the Sprint: Making Technical Decisions That Bind, Inform, and Endure

Every engineering team of sufficient age has experienced the following sequence. A question arises—which database should we use for this service, how should we handle cross-service authentication, what is our policy on third-party dependencies—and a lengthy discussion ensues. A decision is reached. Several months later, the question arises again, as though the previous discussion never occurred. The same arguments are rehearsed. A similar, but not identical, conclusion is drawn. The inconsistency compounds quietly across the codebase until a new engineer asks, with genuine bewilderment, why two adjacent services make diametrically opposite choices about the same problem.

This is not a failure of intelligence. It is a failure of institutional memory, and it is almost entirely preventable.

The British legal system solved an equivalent problem centuries ago. The doctrine of stare decisis—the principle that decided cases create binding precedent for future decisions—was not devised as an administrative convenience. It was a recognition that consistent, reasoned decision-making across time and across practitioners requires a formal mechanism for recording not just what was decided, but why, and under what circumstances a different conclusion might be warranted.

Engineering teams have an analogue in Architectural Decision Records. The problem is that most teams use them the way most people use gym memberships: with good intentions, inconsistently, and without the structural accountability that would make them genuinely useful.

The Anatomy of a Legal Precedent

A common law judgment does not merely state an outcome. It contains the facts of the case, the legal arguments advanced by both parties, the reasoning by which the court reached its conclusion, and—critically—the ratio decidendi: the binding principle that future courts must apply to materially similar situations. Surrounding this core is the obiter dicta: observations that inform but do not bind, useful for analogical reasoning in cases that differ in relevant ways.

This structure is worth examining carefully, because it is considerably more sophisticated than the typical ADR template, which tends to record a decision and a brief rationale whilst omitting the alternatives seriously considered and the conditions under which the decision might be revisited.

A precedent-grade technical decision record should contain, at minimum: the problem statement in sufficient detail that a future reader can assess whether their situation is materially similar; the options considered and the specific objections raised to each; the decision reached and the reasoning that produced it; the constraints and assumptions that underpinned that reasoning; and the conditions under which the decision should be treated as expired or subject to appeal.

That final element is particularly important and almost universally absent from engineering documentation. Legal precedent can be overturned, but only through a formal process that requires the overturning court to engage explicitly with the earlier reasoning and explain why circumstances have changed sufficiently to warrant a different conclusion. Engineering teams that lack an equivalent mechanism will find that decisions are silently overridden rather than formally reconsidered—a practice that produces inconsistency without producing learning.

The Searchable Precedent Library

A legal precedent is only useful if it can be found. The development of systematic law reporting in England—beginning with the Year Books of the thirteenth century and formalised through the Law Reports from 1865—was as important to the common law's success as the doctrine of precedent itself. A court that cannot locate a relevant prior decision cannot be bound by it.

Most engineering teams store their decision records in locations that are, in practice, unsearchable. A Confluence space that has not been curated in two years, a GitHub repository with no consistent tagging or categorisation, a Notion database that predates the current team's tenure—these are archives, not libraries. The distinction matters enormously.

Building a genuinely useful technical precedent library requires treating the findability of decisions as a first-class concern. This means consistent categorisation by problem domain (data persistence, inter-service communication, authentication, observability), tagging by technology and pattern, and a search interface that allows a new engineer to ask 'have we decided how to handle distributed transactions?' and receive a relevant answer within thirty seconds.

The investment required is not trivial, but the return is measurable. Onboarding time decreases when new engineers can understand the reasoning behind the system they have inherited rather than merely its current state. Repeated arguments cease when the record of the previous argument is readily accessible. And the quality of new decisions improves when engineers can see how similar problems were reasoned through in the past.

Binding, Persuasive, and Expired Precedent

Not all legal precedent carries equal weight. Decisions of the Supreme Court bind all lower courts. Decisions of the Court of Appeal bind the High Court. Decisions from other jurisdictions are persuasive but not binding. And precedents can be distinguished—set aside as inapplicable—when the facts of the current case differ in a materially relevant way.

This hierarchy maps usefully onto engineering organisations. Decisions made at the architectural level by the principal engineers or the technical leadership group should carry binding weight for individual service teams. Decisions made by a single team are persuasive guidance for other teams facing similar problems, but may legitimately be departed from when local constraints differ. And all decisions should carry an implicit expiry condition: a technology choice made in 2019 under specific infrastructure constraints should not be treated as binding in 2025 when those constraints no longer apply.

Formalising this hierarchy requires engineering leaders to be explicit about which decisions are organisation-wide standards and which are team-level recommendations. The absence of this clarity is itself a governance failure, and it produces the worst possible outcome: engineers who cannot tell whether they are permitted to make a different choice, and who therefore either seek unnecessary approval or proceed without accountability.

The Appellate Function

The British court system provides a mechanism for challenging decisions that are believed to be wrong: the appeal. This is not a sign of systemic weakness; it is a feature of a mature decision-making institution. The ability to challenge a precedent, through a defined process and with appropriate justification, is what prevents the system from calcifying around decisions that were reasonable when made but have since become obstacles.

Engineering teams need an equivalent. When a developer believes that an established architectural decision is producing poor outcomes, there should be a defined path for raising that challenge—not an informal conversation with a sympathetic manager, but a structured process that requires the challenger to engage with the original reasoning, articulate why circumstances have changed, and propose an alternative with its own documented rationale.

This is not about creating bureaucracy. It is about ensuring that when decisions change, the change is visible, reasoned, and recorded. The alternative—silent divergence from established patterns—is the mechanism by which codebases become incoherent.

Precedent as Professional Maturity

The common law tradition did not emerge from a desire to constrain judicial creativity. It emerged from a recognition that consistent, reasoned decision-making is a form of professional respect—for the parties who depend on predictable outcomes, for the practitioners who must apply the law across different contexts, and for the institution itself, whose authority rests on the perception that it decides like cases alike.

Engineering teams that build a serious precedent practice are making the same statement: that their decisions are reasoned rather than arbitrary, that their institutional knowledge is a shared asset rather than an individual possession, and that future colleagues deserve to inherit a system they can understand and trust. That is, in the end, what professional software development looks like.