Technical Decisions Are Judicial Rulings

Transfers

The judicial-rulings metaphor maps the structure of legal precedent onto the dynamics of technical decision-making in engineering organizations. Where the territory metaphor focuses on who controls decisions, this metaphor focuses on how decisions persist — why past choices constrain present options, and what it costs to reverse them.

Key structural parallels:

• Binding precedent (stare decisis) — in common-law systems, a court’s ruling on a legal question binds all lower courts in the same jurisdiction. A trial court cannot simply disagree with an appellate ruling; it must follow it or distinguish its case on the facts. This maps directly onto architectural decisions in engineering organizations. Once a team chooses PostgreSQL over MongoDB, defines an API contract, or adopts a microservice boundary, that decision becomes precedent. Subsequent teams must work within the constraints of that decision or undertake the costly process of overturning it. The metaphor captures the binding quality of technical decisions — they are not suggestions or preferences but constraints with enforcement mechanisms (code that depends on them, teams that have built around them, documentation that assumes them).

• Authority over correctness — a judicial ruling’s force derives from the legitimacy of the court, not from the quality of its reasoning. A poorly reasoned Supreme Court decision is still binding; a brilliantly reasoned law review article is not. Similarly, a technical decision’s persistence depends more on who made it and through what process than on its ongoing technical merit. A decision made by the CTO in an architecture review carries more precedential weight than a better decision suggested by a junior engineer in a Slack thread. The metaphor exposes how technical organizations, despite their meritocratic self-image, operate through authority hierarchies that determine which decisions “stick.”

• The cost of overturning — reversing judicial precedent requires either a higher court (the Supreme Court overturning its own prior ruling) or legislative action (Congress passing a statute that supersedes the judicial interpretation). Both are deliberate, costly, and politically charged. In engineering, the equivalent is a formal architecture review, a migration project, or a rewrite. The cost of reversal is not merely technical; it includes the political cost of telling teams that their work was built on a foundation that is being torn up, the organizational cost of re-negotiating downstream decisions, and the reputational cost to the original decision-maker. The metaphor explains why bad decisions persist: overturning them is expensive even when everyone agrees the original ruling was wrong.

• BDFL as Supreme Court — the “Benevolent Dictator For Life” model in open-source projects (Guido van Rossum for Python, Linus Torvalds for Linux) is structurally a supreme court of one: a single authority whose rulings on technical questions are final and binding. The BDFL’s decisions become precedent not because they are debated and refined through adversarial process but because the BDFL’s authority is recognized as supreme. When a BDFL steps down (as Guido did in 2018), the project must design a replacement governance structure — the equivalent of a constitutional convention.

Limits

• No formal appeals process — the judiciary has a structured hierarchy of review: trial court, appellate court, supreme court, each with defined jurisdiction and procedures. Most engineering organizations have no equivalent. Technical decisions are reversed through informal channels: a new VP arrives and mandates a different stack, a team quietly migrates away from the official standard, or the original decision-maker leaves and their ruling loses its enforcer. The metaphor imports a formality and procedural rigor that engineering governance typically lacks, which can make ad-hoc decision reversal feel more illegitimate than it should.

• Missing opinions — judicial rulings are accompanied by written opinions that explain the court’s reasoning, cite precedent, and address counterarguments. These opinions are the primary mechanism by which precedent is transmitted: future courts read the opinion, not just the ruling. Most technical decisions lack equivalent documentation. Architecture Decision Records (ADRs) are the closest analogue, but they are rarely maintained with the rigor of judicial opinions. The result is binding precedent without comprehensible reasoning — engineers must follow the ruling but cannot understand why it was made, making it impossible to determine whether new circumstances warrant reversal.

• Inertia masquerading as principle — the doctrine of stare decisis has principled justifications: predictability, fairness, and the rule of law. Technical decision persistence rarely has such justifications. Most technical precedent persists because reversal is expensive and no one has the energy to pursue it, not because the original reasoning was sound or because consistency serves a higher principle. The judicial metaphor elevates what is often mere inertia to the level of principled governance, which can discourage the healthy questioning of outdated decisions.

• Distinguishing is too easy — in law, “distinguishing” a case (arguing that the facts are different enough that the precedent does not apply) is a rigorous process with standards of argumentation. In engineering, distinguishing is trivially easy: “Our team is different,” “Our use case is special,” “That decision was made before we had Kubernetes.” The metaphor does not import the discipline of legal distinction, only the concept, making it a rhetorical tool for both enforcing and evading precedent as convenient.

Expressions

• “That’s settled law” — a technical decision that has been made and is not up for debate
• “We need to relitigate this” — reopening a previously closed technical decision for reconsideration
• “The ADR is the written opinion” — framing Architecture Decision Records as the engineering equivalent of judicial opinions
• “Guido is the Supreme Court of Python” — the BDFL model as judicial authority
• “That decision has been overturned by the new VP” — a higher authority reversing established technical precedent
• “Distinguishing your case” — arguing that a general technical standard does not apply to your team’s specific circumstances

References

• Tyree, Jeff, and Art Akerman. “Architecture Decisions: Demystifying Architecture.” IEEE Software 22.2 (2005) — the ADR as a mechanism for recording technical precedent
• Nygard, Michael. “Documenting Architecture Decisions.” (2011) — lightweight ADR template widely adopted in software engineering
• Llewellyn, Karl N. The Common Law Tradition: Deciding Appeals (1960) — how judicial precedent actually operates in practice, illuminating the gap between formal doctrine and real behavior