ADRs Are The Antidote to "Because That's How We've Always Done It"

Few phrases frustrate me as much as, “Because that’s how we’ve always done it.”

The phrase sounds like an explanation, although it provides no reasoning. It asks the listener to accept a practice because the practice already exists. The people who made the original decision may be gone. The conditions that shaped it may have changed. The risks, constraints, conversations, and rejected alternatives may have disappeared from memory. All that remains is the conclusion.

That is how a decision becomes a tradition.

The problem is not that old decisions are necessarily wrong. Many were thoughtful responses to difficult circumstances. The problem is that a future team may inherit the action without inheriting the reasoning. Once that happens, the organization no longer knows whether it is preserving a wise safeguard, repeating an obsolete compromise, or following a habit whose purpose disappeared years ago.

An Architecture Decision Record, commonly called an ADR, helps prevent that loss.

An ADR captures a decision at the moment it is made. It records what the team knew, what remained uncertain, what constraints mattered, what alternatives were considered, why one option was selected, and what consequences the team anticipated. An ADR preserves enough context for someone in the future to understand the decision as more than an unexplained instruction.

That distinction matters.

“Do this because the people before us did it” discourages discernment. It discourages conversation. It puts an end to the discussion before the discussion can get started.

A better mindset is, “Before changing this, here is what the people before us knew” because it supports discernment.

The Stop Sign We Do Not Understand

Consider a stop sign at an intersection well outside of town.

A driver approaches and sees no traffic. The roads appear quiet. Visibility seems adequate. The sign may appear unnecessary, particularly to someone who has traveled through the intersection many times without seeing another vehicle.

What the driver cannot see is the curve just beyond the intersection. Traffic can emerge from that curve quickly, and drivers approaching from that direction may have an incomplete view of the crossing. The condition can change from no cross-traffic to fast-moving cross-traffic in seconds.

The stop sign is a message from the past.

It communicates that someone identified a danger that may not be visible from the driver’s current position. Perhaps there was an accident history. Perhaps engineers studied the sightline. Perhaps local residents described repeated near misses. The sign does not explain the entire story, although it preserves the action that resulted from it.

An ADR can preserve more than the sign. An ADR can preserve the reason the sign exists.

Without that context, a future decision-maker may remove a safeguard because the danger is not immediately apparent. The absence of visible danger may be mistaken for evidence that no danger exists.

Software systems are full of these intersections.

A strange configuration, inconvenient control, unusual dependency, restricted deployment window, or apparently inefficient process may exist because someone learned something that is no longer obvious. That does not mean every inherited practice deserves to remain. It means the practice deserves to be understood before it is changed.

Different People See Different Parts of the Intersection

Technical decisions rarely exist within a purely technical world.

I once worked at a university where a network consultant was brought in to help modernize portions of the wireless infrastructure. The consultant recommended making a significant change in late April. The timing was convenient from the consultant’s perspective. Hardware would be available, technicians could be scheduled, the weather would be cooperative. The last week of April seemed perfect.

From the institution’s perspective, however, late April carried a different meaning.

Registration for the fall semester was underway. Spring examinations were about to begin. Staff members depended upon network access to support registration, scheduling, student services, and academic operations. Faculty members were preparing course materials, conducting exams, and completing end-of-semester responsibilities. Students were registering for classes, submitting work, and relying upon systems whose availability affected their progress.

A prolonged network outage during that period could have caused consequences far beyond temporary technical inconvenience.

The consultant’s recommendation was not necessarily careless. The consultant was working with one portion of the available knowledge. The people responsible for academic operations possessed another portion. The technical work and the institutional calendar intersected in ways that were not visible from a single vantage point.

Cross-functional teams matter for this reason. The developer sees the application. The network engineer sees the infrastructure. The security practitioner sees exposure. The project manager sees dependencies and schedules. The support team sees how failure reaches users. A business or institutional leader may understand obligations that do not appear in a system diagram.

Each person can be correct within the boundaries of what that person sees. The decision improves when those perspectives are brought together.

An ADR gives those perspectives somewhere to survive after the meeting ends. It can record that a change was postponed because of registration, examinations, contractual deadlines, regulatory obligations, staffing limits, or another condition that may not be obvious to someone reviewing the technical work months later. Without that record, future team members may remember only that changes are never made in late April. Eventually, someone asks why and receives the familiar answer: “Because that’s how we’ve always done it.”

The original reasoning has decayed into ritual.

When Fragile Architecture Tells an Incomplete Story

I explore a more consequential version of this problem in Chapter 5 of my upcoming book, How to Work with Technical Teams Without Losing Your Mind (or Your Job).

I inherited a critical system whose architecture appeared dangerously fragile. It consisted of 128 tightly interlinked parts. A failure in one component would have caused catastrophic and irreversible loss. The system had no conventional backups, no geographic redundancy, and no straightforward recovery path.

My first judgment was harsh. I struggled to understand how competent engineers could have created something so precarious.

That judgment changed as I reconstructed the conditions under which the system had been designed.

The original team had considered other approaches. Those alternatives failed under the required load. The team faced budget limits, demanding performance requirements, policy restrictions, a strict deadline, and an uptime requirement that allowed less than five minutes of downtime per month. The architecture that looked reckless from the outside had been the only design that the team found that worked within the conditions imposed upon them.

What appeared to be negligence was ingenuity under pressure.

The system had not changed, but my understanding of it had.

The original team may have known exactly how much risk the design carried. The people who inherited it received the architecture without receiving the reasoning. A conscious compromise became an unconscious inheritance. “We selected this design because the safer alternatives could not satisfy these constraints” gradually became, “This is how the system works, and nobody knows why.”

An ADR could have preserved the missing bridge.

It could have recorded the alternatives that failed, the constraints that eliminated them, the risks the team knowingly accepted, and the conditions under which the decision should be reconsidered. It could have warned future engineers without requiring them to rediscover the danger personally.

It also could have protected the reputation of the people who made the original decision.

Without context, successors may interpret an unusual design as evidence of incompetence. With context, they may see intelligence, restraint, creativity, or a difficult compromise made under conditions that allowed no ideal answer. Documentation cannot guarantee charitable judgment, although it can provide the evidence needed for fair judgment.

Knowledge, Discernment, and Action

I organize much of my work around a progression I call KDA: Knowledge, Discernment, and Action.

Each stage depends upon the one before it.

Knowledge establishes what is known, what is uncertain, what has been tried, what constraints exist, and what risks are present.

Discernment weighs those facts. It examines tradeoffs, competing needs, consequences, reversibility, cost, timing, and the human effects of the available choices.

Action follows from that discernment.

Teams often get into trouble when they jump from incomplete knowledge directly to action. Someone sees an awkward architecture and replaces it. Someone encounters a control that creates friction and removes it. Someone notices an unusual maintenance window and changes it. The action may appear reasonable within the visible facts while remaining dangerous within the larger context.

AI-assisted development can amplify the same failure mode when a tool acts on the visible implementation without access to the reasoning that shaped it.

ADRs support the entire KDA sequence:

They preserve knowledge for people who were not present.

They preserve evidence of discernment by documenting alternatives, tradeoffs, and reasoning.

They support better action by helping future teams determine whether to preserve, revise, supersede, or replace the original decision.

The enduring value of an ADR is therefore greater than the decision itself. An ADR preserves the discernment that produced the decision.

A Gift to People We May Never Meet

There is a practical business case for ADRs. They reduce duplicated investigation, repeated experiments, architectural drift, and costly misunderstandings. They help teams identify accepted risks and revisit them when conditions change. They make onboarding easier and support continuity when experienced people leave.

There is also a human case.

Writing an ADR is an act of consideration for the people who will inherit our work.

Those people may join the team years later. They may be asked to support systems we designed, enforce policies we selected, or live with compromises we accepted. They may arrive during an incident, under pressure, with little time to reconstruct years of history from tickets, commit messages, and fragments of conversation.

We may never meet them.

We can still leave them more than unexplained machinery.

We can tell them what we knew. We can identify what worried us. We can explain what we tried, what failed, and what we accepted. We can warn them about the curve beyond the intersection.

That is professional courtesy. It’s also stewardship.

ADRs Are Not Eternal Decrees

An ADR should not become another form of “because that’s how we’ve always done it.”

The purpose of an ADR is not to place a decision beyond question. Its purpose is to make informed questioning possible.

Technology changes. Budgets change. Regulations change. Organizational priorities change. An architecture that was appropriate a year ago may be unnecessarily risky today. A control that once protected the system may have been superseded by a better mechanism. A compromise made under severe constraints may no longer be necessary.

A healthy ADR practice allows decisions to be superseded while preserving the chain of reasoning.

A future team should be able to say, “This was a reasonable decision when it was made. The conditions that justified it may have changed enough to warrant reconsideration. Here is the new decision, and here is why we are making it.”

That is not disrespect for the past. It is responsible continuity.

Fewer Incidents Through Better Memory

Institutional amnesia creates incidents.

Teams repeat failed experiments because nobody recorded that they had already been tried. Engineers remove safeguards whose purposes are no longer visible. Accepted risks become forgotten risks. Cross-functional knowledge disappears when people leave. New team members act on incomplete context and unintentionally recreate old problems.

ADRs cannot eliminate failure. They can reduce the likelihood that missing context becomes the cause of it.

They preserve knowledge so that discernment remains possible. They preserve discernment so that action can be proportionate. They give future teams the ability to reconsider earlier decisions without dismissing them, repeating them blindly, or judging their predecessors without evidence.

“Because that’s how we’ve always done it” asks us to inherit a conclusion.

An ADR gives us the opportunity to understand.