Orthogonality — 01: Choosing Coordinates for Complexity
An architecture is not just a way to organize code — it is a choice of coordinates for a system's variation, and a bad basis makes one conceptual change move five files at once.
A statistical model is a representation, often in considerably idealized form, of the data-generating process. A dataset is a representation of a population, in the variables someone chose to measure. A software architecture is a representation of a system, which comprises software elements, relations among them, and properties of both. An LLM, an agent, even a set of tools all make some choice about what structure should be made explicit and what should disappear into the background.
The objects are very different. The representation problem is not.
Take a factor model:
We are not claiming that reality is literally made of a few factors and some leftover noise. We are choosing a set of dimensions through which variation becomes describable.
A dataset does something similar. Reality does not naturally arrive as rows, columns, features, labels, and sampling intervals. We choose those coordinates.
Software architecture makes the same kind of choice. A system contains users, events, models, permissions, workflows, policies, interfaces. Which of these become primitive concepts? Which differences deserve to be represented explicitly?
Before doing anything with complexity, we choose how to see it.
So what makes one representation better than another?
Mathematics has a particularly clean version of this problem. Suppose we choose a set of directions
and represent some object as
A basis is, in one sense, just a choice of coordinates. The object has not changed. What changed is what counts as a direction, and therefore what the coefficients mean.
The first thing we want from those directions is obvious: they should be enough. If
then every object in the space can be represented using them. Span gives us expressive power.
But expressive power turns out to be a rather weak standard. Two different bases may span exactly the same space while making that space look completely different. One might give each coordinate a clean interpretation. Another might force every meaningful change to appear as a simultaneous movement across several coordinates.
Both representations are complete. Only one is pleasant to think in.
This is where orthogonality becomes interesting. For orthogonal directions,
The geometric picture is familiar: the directions meet at right angles. But the right angle is not really the point.
The useful property is that different coordinates capture distinct variation. Movement along one direction does not secretly require compensating movement along another.
A representation stops being merely expressive and starts becoming separable.
This is why orthogonal decompositions appear everywhere in mathematics. Once the directions are separated, we can ask how much of an object lies along one direction without first untangling all the others. The coordinates become individually legible.
Fourier analysis is perhaps the cleanest example. A complicated signal in the time domain may look like one inseparable waveform. Fourier does not simplify the signal itself. It changes the representation:
Now what looked like one tangled object becomes a collection of frequency components. A low-frequency component can be measured without confusing it with a high-frequency one. One band can be removed. Another can be amplified. Energy can be attributed across frequencies. The original signal can later be reconstructed.
Nothing about the underlying signal became less complex. The coordinates became better aligned with the structure we wanted to reason about.
That distinction matters.
A good representation does not necessarily make a system simpler. It makes its variation easier to separate.
And this is where the idea starts looking less like linear algebra and more like architecture.
Software systems have sources of variation too. A data source may change. A business rule may change. Presentation may change. Model behavior may change. Execution policy may change. An architecture decides, implicitly or explicitly, where those changes are allowed to live.
Consider a seemingly simple change to a business rule. If implementing it requires changing a database schema, a routing layer, a prompt, a UI component, and a validation rule, we usually describe the problem as coupling.
That description is correct, but it may be downstream of something deeper. Perhaps the system has no coordinate corresponding cleanly to the concept that changed.
The business rule exists in the domain, but your architecture represents it only as pieces scattered across five other abstractions. So one conceptual movement in the problem becomes five movements in the implementation. The representation is entangled.
This gives architecture a slightly different interpretation.
Architecture is not only a way to organize code. It is a choice of coordinates for system variation.
A good architecture tries to make important sources of variation separately legible. When one concept changes, there should ideally be somewhere in the representation where that change naturally belongs.
Not every dependency can disappear. Engineering is not an inner-product space, and “orthogonal architecture” is not a formal condition we can satisfy.
The useful part of the analogy is the question it gives you:
What are the actual directions along which this system changes?
Sometimes the answer to a messy architecture is another abstraction. Sometimes it is fewer abstractions. And sometimes the primitives themselves are wrong.
What looks like refactoring may really be a change of basis.
The underlying behavior remains the same. We choose new coordinates in which its structure becomes easier to see.
That is the deeper reason orthogonality matters here. Separation is not valuable for its own sake. It is valuable because complexity becomes legible when different sources of variation have distinct places to live.
A bad architecture can be a bad choice of coordinates.
For an agent, then, the next question is rather literal:
What should those coordinates be?