Patterns First, Details Second
Why mapping relationships before jumping to solutions is one of the most useful design skills in software and beyond
One of the things I love about building software is that, after a while, you stop seeing individual lines of code and start seeing patterns.
A dependency graph. A feedback loop. A bottleneck. A boundary. A network. A system that has evolved around a constraint.
I've noticed the same thing when looking at landscapes.
Where You Start Matters
You rarely begin by asking, "Where should I put this one thing?"
You start by mapping relationships.
- Where does water naturally move?
- Where does energy enter the system?
- Which elements are visited most often?
- Where are the edges?
- What supports what?
- Where does waste from one process become an input for another?
This is remarkably close to how I think about software architecture.
Relationships Over Components
In good code, components don't exist in isolation. Their relationships are often more important than the components themselves.
A database isn't interesting because it is a database. Its value comes from what depends on it, what feeds it, what it enables, and what happens when it becomes unavailable.
The same is true of a function. Or a team. Or a garden.
The Temptation to Jump to Details
It's tempting to pick the technology, draw the components, define the interfaces and start implementing.
But sometimes the better first step is simply to map the system.
This idea has a surprisingly deep history in design. Bill Mollison explicitly described design as assembling components in patterns and relationships. One of the principles associated with his work is relative location: understanding elements through their relationships rather than in isolation.
There's also a useful connection to Christopher Alexander's work on pattern languages: recurring problems can have recurring structures that provide reusable solutions.
That resonates strongly with software engineering.
We Already Do This
We call them architectures, patterns, abstractions, protocols, conventions and primitives.
The names change. The underlying activity doesn't:
Observe → identify patterns → understand relationships → compose a system → refine the details.
Complexity rarely comes from one complicated thing. It comes from many relatively simple things interacting.
If you only look at the things, you miss the system.
If you map the relationships, the system starts explaining itself.
Before trying to solve the problem, step back far enough to see the pattern.
#software #architecture #engineering #design #systems