Why Is More Important Than How

The second law of software architecture: a design only makes sense once you know why it was chosen.

The code preserves how a system is built; the why survives only if someone records it.

To an executive

Anyone can see what we built, but the reasons vanish when people leave. Recording why we chose it lets us change course with confidence, not guesswork.

To an engineer

Write down the reasoning, alternatives and trade-offs, not just the design. Review whether the reason still holds before you keep or reverse a decision.

The idea

In Fundamentals of Software Architecture, Richards and Ford propose two laws: everything in software architecture is a trade-off, and why is more important than how. Anyone can see how a system is structured by reading the code; the reasoning behind it disappears unless it is recorded.

Without the why, teams cannot tell an essential constraint from an accident of history, so they either preserve everything or break things they shouldn't. In later writing the authors draw the line sharply: questions of how to implement something have documented answers, while questions of what you should do depend on local context that only the people involved know.

Why it works

The how is recoverable; the why is not. Structure can be read from code, configuration and diagrams. Constraints, rejected options and trade-offs exist only in people's heads until someone writes them down.

Reasons make decisions revisitable. If you know why a choice was made, you can check whether that reason still holds. If you do not, the only options are blind faith or blind change.

Trade-offs depend on context. Because every choice is a trade-off, the same design can be right in one organisation and wrong in another. The why captures the context that made it right here.

Where it applies

Design reviews, where the first question should be why, not how.
Inherited systems, where newcomers need to separate constraints from accidents.
Architecture documentation, which too often shows structure without rationale.
Conversations with stakeholders, who care about the reasons and consequences, not the mechanics.

How to apply

Ask why before how in every design discussion: what problem, which constraints, what alternatives.
Record the reasoning for significant decisions, for example as ADRs with context and consequences.
Name the trade-offs accepted, not just the benefits gained.
Note what would change the decision, so others know when to revisit it.

Example scenario

Two services shared a database and nobody remembered why. One team assumed it was a mistake and wanted to split it immediately; another assumed it was essential and refused to touch it.

An old decision record explained that the sharing had been a temporary measure for a data migration, with a note that it could be removed once the migration finished. The migration had ended a year earlier. With the reason gone, the teams agreed to split the database in the next quarter.

Questions to ask

Why was this chosen, and is that reason still true?
Have we written down the why, or only the what?
What would have to change for us to reverse this decision?

When not to use it

Trivial or easily reversible choices, where recording the reasoning costs more than rediscovering it.
Exploratory work, where the why is still being worked out and writing it down too early fixes a guess.

How it misleads you

Endless justification documents. Record the key reasons concisely and move on. A rationale written after the fact to defend a decision is also misleading: it records the argument that won, not the reasoning that was actually used.