machu

Posted on Mar 14 • Edited on Mar 15

Git Archaeology #4 — Backend Architects Converge: The Sacred Work of Laying Souls to Rest

#opensource #productivity #git #career

Departed Architects leave souls in the codebase. Laying them to rest is sacred work.

Previously

In Chapter 3, I explored a frontend team and discovered two evolution paths for Architects:

Inheritance Architect: Anchor → guards and refines existing structure
Emergent Architect: High-Gravity Producer → creates new gravitational fields

In frontend, multiple aesthetics of structure can coexist. This means multiple Architect candidates can emerge. Structural competition happens.

But when I ran EIS on a Backend team, I saw a completely different landscape.

The Backend Team Portrait

Here's the Backend team's data:

And the team metrics:

1 Architect. 3 Anchors. 0 Producers.

This is a completely different structure from frontend.

Why Backend Architects Concentrate

In frontend, multiple Architects can emerge.

In backend, that rarely happens.

The reason is simple.

Backend has "correct answers" for structure.

For example, backend systems often have stable patterns like:

Domain layer
Presentation layer
UseCase layer
Infrastructure layer
Transaction boundaries
Event boundaries

These design patterns have reusable structures across many systems.

In other words:

FE	Multiple aesthetics of structure exist
BE	Correct answers tend to exist

Because of this difference, Backend Architects concentrate rather than proliferate.

Think of it like a solar system:

This structure isn't unusual for Backend teams.

The Soul of a Departed Architect

Look at Y.Y.:

Y.Y. is a departed Architect.

But even with time decay applied, they're still ranked #2 on the team.

What does this mean?

The assets they created are still massively present in the codebase.

What Former State Means

In EIS, Former state is only detected when significant assets remain.

Former state conditions:

Raw Survival (no time decay) is high
Survival (with time decay) is low
AND Design or Indispensability is high

This means: "This person once shaped the structure. They're no longer active. But their code remains."

You don't become Former just by leaving. Only those who left assets worth leaving become Former.

Y.Y. meets exactly these conditions.

Still #2 Despite Time Decay

This is the emotional part.

EIS uses time-decayed Survival. Code from 2 years ago has a weight of just 0.02.

And yet Y.Y. is still #2.

This means they continue to have massive influence on the codebase even after departure.

This isn't "the afterimage of someone who was once strong."

It's real assets that still support the codebase today.

Laying the Former to Rest

But Former state has another meaning.

It's something that needs to be laid to rest.

The team metrics show:

Legacy-Heavy means strong but historically heavy team.

Departed members' code remains in large quantities. That's not inherently bad — good design is why it remains.

Good Design Creates Common Sense

Here's an important fact.

This team hasn't collapsed.

Several modules that only Y.Y. touched still exist. Most of git blame belongs to the Former member.

Yet the team functions normally.

Why?

Because those modules were built under well-organized design.

We received verbal handoffs. But complete documentation or knowledge transfer didn't happen. Still, the design embedded as structure in the code gives later engineers a certain understanding.

This is what I call "good design creates common sense."

Excellent design doesn't necessarily require complete documentation or knowledge transfer. The structure of the code itself communicates the module's intent and usage.

Strong design leaves knowledge in structure, not in people. And that structure creates shared understanding across the team.

Legacy-Heavy Converges

EIS currently handles quantitative metrics like history and code survival rates. "Common sense through design" — why Former members' code still functions healthily — can't be directly observed yet.

If that became possible, we could distinguish between "structurally healthy despite heavy history" and "truly dangerous dependency structures."

But we may not need to measure that far.

Strong teams gradually replace Former members' code with their own. Legacy-Heavy resolves over time. It converges toward the right state.

EIS can naturally capture this convergence process through Survival trends and Risk Ratio changes.

However, as time passes, the risk that fewer people understand that code increases.

That's why laying the Former to rest becomes necessary.

Souls Get Absorbed into Debt

What does laying a Former to rest mean?

It means being absorbed into Debt Cleanup.

Active members touch Former's code. Understand it. Fix it. Rewrite it.

Then Former's blame lines decrease. They're replaced by active members' lines.

This is laying to rest.

EIS visualizes this process:

Former's Survival gradually decreases
Active members' Debt Cleanup increases
Team's Legacy-Heavy degree decreases

This is sacred work.

The departed Architect's soul, through active members' hands, gradually dissolves into the codebase.

The True Meaning of Anchor

This Backend team has 3 Anchors:

Y.Y. (Former)
P.
R.S.

Anchor isn't just "quality guardian."

Anchor means structure-understanding engineer.

Anchor traits:

Deep understanding of existing structure
Doesn't break structure
Guards quality
Maintains system integrity

In other words, Anchor is an engineer who understands structure and produces on top of it.

And in Backend, this Anchor becomes the evolution path to Architect.

Backend Architect Evolution

In frontend:

But in Backend, this is more common:

This is the Convergent Evolution Model.

The Reproducing Architect

Backend Architects are characterized by being able to reproduce structure.

Say a design like this worked in one codebase:

A skilled Backend Architect can reproduce that structure in a different system.

So Backend Architect means:

Someone who creates structure
AND someone who can reproduce structure

If FE Architects are the type who "create emergent new structures," Backend Architects are the type who "purify and reproduce structures."

Producer Vacuum

Another interesting point.

This team has no Producers.

Producer means "someone who doesn't fully understand structure but produces on top of it."

Without Producers, team structure looks like:

This is a state I'd call Producer Vacuum.

With Producers:

A three-layer structure forms.

This is the most stable form for Backend teams.

Architect Bus Factor = 1

EIS raises warnings for this team:

This means Architect Bus Factor = 1.

If the Architect leaves, team productivity density drops significantly.

This is the most typical risk for Backend teams.

In frontend, Emergent Architect candidates can mitigate this problem.

But in Backend, because correct structural answers exist, Architects tend to concentrate.

Result: Bus Factor risk increases.

Prescription for This Team

What does this Backend team need?

Fill the Producer layer: Allow reverse flow from Anchor → Producer. Create an environment where people can produce without fully understanding structure
Accelerate laying Former to rest: Active members take over departed Architect's code. Consciously increase Debt Cleanup
Open the Anchor → Architect path: Let structure-understanding Anchors participate in design decisions

2 is especially important.

Legacy-Heavy state isn't "bad." It's proof that good design remains.

But understanding it, taking it over, and rewriting when needed — someone has to do that work.

That work is visualized as Debt Cleanup.

FE vs BE Evolution Models Compared

Summary:

	FE	BE
Structure	Multiple aesthetics exist	Correct answers tend to exist
Architect	Can distribute	Tends to concentrate
Evolution Model	Branching (Emergent or Inheritance)	Convergent (Inheritance dominant)
Risk	Structural collision	Bus Factor concentration

Neither is better.

The nature of the domain determines the evolution model.

EIS visualizes these differences and can suggest appropriate prescriptions for each.

Being Honest

My score of 92.4 at #1 feels good — like my ability as an Architect is being validated.

But honestly, I also work an absurd number of hours.

And there's another thing that makes me happy.

I could only achieve this Architect score because I inherited solid design from Y.Y. and made it even better.

Backend has time-tested good design passed down through generations — structures refined by those who came before. I learned them and built on them. Y.Y. also learned them and built on them. When we met, we already shared the same understanding. That's why common sense emerged and inheritance became possible.

On top of that foundation, I added delegateProcess and partProcess — not textbook patterns, but ones I'm convinced are useful. I enhanced existing concepts that already had business impact. I organized and modeled new core business functionality well.

That accumulation is what these numbers represent.

I worked with P. before, at another company. We merged our design knowledge back then. So we share common understanding of each other's design approach. Whatever their current score shows, I know they have horsepower. I know they have the ability to hit 80+ on our team.

R.S. is doing really good work. When I invited them to join this team, they said "I lack confidence because I don't have much experience." But from my experience, I was absolutely certain they could do good work. So I invited them. And now, they've become an Anchor. An Anchor on an Elite team. That's something to brag about anywhere. Deeply moving.

And even more honestly, what I really want to brag about is the team.

That this team gets an Elite classification. That it functions despite carrying Legacy-Heavy weight. That it's moving forward while laying departed Architects' assets to rest.

One of my motivations for building EIS? I wanted to brag about this team.

I wanted to say "my team is strong." But "somehow strong" isn't convincing.

And critically, I wanted to brag on a playing field where bias can't enter.

When someone subjectively says "that person is strong," it might just be the evaluator's bias. Maybe the person who's good at politics gets high ratings.

But git history doesn't lie.

Does the code survive? Are they involved in design? Are they creating debt, or cleaning it up?

Reverse-engineering from history leaves no room for bias.

So I built the numbers on this playing field.

Of course, this isn't everything.

Whether the product that emerges is good, whether it fits the market — that needs to be judged on a different axis.

EIS measures technical impact on the codebase. But product value isn't determined by code quality alone. Is it reaching users? Is it viable as a business? That's a different conversation.

EIS visualizes "strength as a technical organization." What you build on top of that is a separate decision.

And those numbers matched my intuition. The team really was strong.

Spec Changes and Robust

A team member asked:

Do spec changes that overwrite code get reflected in Robust scores?

Yes, they do.

When spec changes cause code rewrites, the original author's Robust score drops.

This means planner precision also affects these scores.

If specs are unstable, code gets rewritten. If planning is sloppy, no matter how good the code an engineer writes, it disappears.

That this team achieves strong Robust scores isn't just an engineering achievement. It's the achievement of the entire development organization, including planners.

Renovations and Scores

Another question came up:

If we do a major renovation, will the people who wrote pre-renovation code see their scores drop?

Yes.

If renovation replaces previous code, the previous authors' scores drop.

But here's the key point.

Can you adapt?

Can you weave your opinions into the post-renovation design?
Can you produce scores even on top of the new good design?
More broadly, can you produce scores across multiple codebases, whether they're good or bad?

That's what real engineering strength is.

Scoring high on one codebase is possible if you're lucky with your environment.

But being able to adapt and generate gravity on any codebase, any team — that's what a real engineer looks like.

EIS measures impact on a single codebase. But if you repeat that measurement across multiple codebases, you start seeing reproducibility that transcends environment.