The cathedral and the bazaar are both wrong, or at least incomplete. When we talk about software architecture, we tend to reach for metaphors from the physical world — buildings, bridges, plumbing — but these comparisons obscure more than they reveal. A bridge, once built, does not need to accommodate the possibility that gravity might work differently next quarter.
The Shape of Decisions
Every system is a fossil record of the decisions that created it. The database schema reflects what someone thought the domain looked like in 2019. The API boundaries reflect the org chart of the team that built version one. Conway’s Law is not merely an observation; it is a force of nature as reliable as entropy.
What makes architecture interesting is not the individual decisions but their interactions. Choose a microservice boundary here, and you create a coordination problem there. Normalize a database table for correctness, and you accept a performance cost that will compound over years. Each choice constrains future choices in ways that are difficult to predict and impossible to fully enumerate.
The Illusion of Reversibility
We comfort ourselves with the idea that decisions can be reversed. “We can always refactor later.” This is technically true and practically misleading. The cost of reversing a decision grows exponentially with the number of downstream decisions that depend on it. By the time you realize the original choice was wrong, it has become load-bearing in ways nobody documented.
This is why the most valuable architectural skill is not making good decisions — it is recognizing which decisions are hard to reverse and spending proportional effort on them. Everything else can be fixed in a sprint. But get the data model wrong, choose the wrong consistency guarantees, or draw service boundaries along the wrong axis, and you will be living with the consequences for years.
Toward Pragmatic Architecture
The best architects I have worked with share a common trait: they are deeply uncomfortable with abstraction for its own sake. They want to know the access patterns before designing the schema. They want to see the failure modes before choosing the communication protocol. They treat every layer of indirection as a cost to be justified, not a virtue to be pursued.
This pragmatism extends to their relationship with uncertainty. Rather than trying to design systems that handle every possible future requirement, they design systems that are easy to change in the directions that seem most likely, while remaining honest about which directions those are.