In 1687, Newton watched an apple fall. The grocer watching the same scene thought: "That apple looks weak. Probably tastes bad." Newton asked a different question — not about the apple, but about why it falls. And he discovered gravity.
→ Discovers gravity
→ Judges the fruit
Most people ignore gravity. Because it's invisible. They see the fallen apple. They don't see the force that made it fall.
Software quality is the same. Test documents written retroactively the night before delivery, coverage reports nobody reads, incidents that explode in production — people look at these and judge. "The developers are weak. QA is lazy. The team has no chemistry." But these are just fruit. The gravity making them fall — structural dysfunction, language silos, missing traceability — stays invisible.
SOM was born from the attempt to see that gravity. And SOM Tree is the tool that makes it visible.
A Name Gives Shape
Bonus Episode 4 established it: the moment you name something, it exists.
When a SOM ID is assigned, LOGIN-001 comes into being — and under that name, planning specs, development commits, test cases, defect records, and change history all gather. Scattered things converge on a single coordinate.
But a coordinate is a number. Numbers can be read. They cannot be seen.
SOM Tree takes those coordinates and blooms them into visual form. Numbers become a tree. Names become fruit. Relationships become branches. History becomes roots.
The Language of Trees
Why a tree?
The tree is the oldest living form humanity has ever learned to read. Deeper roots mean older and more stable. Wider branches mean richer. Redder fruit means healthier. Nobody needs to be taught this — they already know.
🍎 🍎 🍎 🍎 🍎
branch ─────────────── branch
trunk
root system
The roots are the project's foundation — the older and more stable the Module, the deeper the roots. The trunk is the system's central axis. The branches are Modules. And each piece of fruit is a SOM ID — an individual Program.
Look at this tree once, and you understand it without any explanation.
What the Fruit Tells You
The color of each fruit is its status.
A branch heavy with red fruit signals something structurally wrong with that Module. A tree dense with green is a healthy system. Nobody needs to explain it — the moment you see the tree, you read the state.
The size of a fruit is its coverage. Large fruit means thoroughly tested. Small fruit means insufficient verification. A bare branch means an untested or still-in-development Module.
Position signals priority. Problematic fruit rises to the top. Healthy fruit hangs abundantly below. The tree shows you where to act first.
The Tree Is Alive
This is not a static diagram.
The tree breathes. Fruit pulses. Branches sway. Energy flows through the trunk.
A fruit with a defect trembles — the vibration travels up the branch to the trunk. Old, stable fruit pulses slowly and heavily. Freshly deployed fruit blinks rapidly. A fruit in warning state glows with a golden ring.
These movements communicate state. No reports to read, no numbers to interpret — look at the tree and you feel it.
Planners, PMs, operations, developers — each speaking a different language, all looking at the same tree. That is often enough.
A Tree That Reveals Gravity
This is where SOM Tree's real value lives.
If a branch keeps turning red — that's not developer error. That's a signal of structural dysfunction in that Module. Gravity is at work there.
If a fruit stays blue indefinitely — testing is being postponed. Why? Schedule pressure? Priority conflict? Development delay? The tree is asking the question.
If a Module has shallow roots — it's young, or it changes frequently. Probably less stable.
The person reading the SOM Tree asks: why is that fruit there?
Software Should Be Beautiful
It is a reasonable demand — that the program you open every day should be beautiful.
We live with software every day. We open it in the morning, stare at it all day, close it at night. The idea that software just needs to function is like saying aesthetic sense is unnecessary if you live in a factory.
SOM Tree is a portrait of software before it is a management tool.
A good portrait captures the subject as it truly is — healthy parts and ailing parts, deep roots and shallow, full branches and bare ones. And a good portrait — you can look at it for a long time without tiring of it.
and feels what needs to happen today. Not data — sensation.
Closing the Bonus Series
The SOM theory series began in Episode 1 with a question.
"Why is quality always written in the developer's language?"
Following that question, we found BOM. We found Sima Qian. We faced organizational inequality. We discovered the philosophy of naming.
And at the end, we reached a tree.
A tree with roots, a trunk, branches, and fruit. Each piece of fruit is a SOM ID. Each branch is a Module. The whole root system is the history of the software we've built.
The tree doesn't explain. It just shows.
And what is visible — is hard to ignore.
They stir too. Even if they don't know it...... those outside the circle of power.