On Fragmentation: Tech Debt Is a Coherence Problem

Tech debt is usually framed as a code quality issue.
This is a category error.

Tech debt is what fragmentation looks like when conflicting constraints, unaligned realities, and delivery pressure get encoded into software.
If you want to understand legacy codebases — and why "fixing" them so often fails — you have to look at coherence, not cleanliness.

1. On Tech Debt, Fragmentation, and "Bad Code"

"Who wrote this code?"
$ git blame
"Oh.. it was me."

A humbling moment in every engineer's career.
If it hasn't happened yet:
It will.
(Sweet summer child.)

What is "Tech Debt", really?

Tech debt is not "bad code".
It's decisions made under pressure.
Under incoherent constraints.
Unaligned goals.
In ambiguity.

Tech debt is the Prefrontal Cortex going:
"Whatever. Good enough for now!"

But software is (often) not written by a single mind.
It's written over time.
By many humans.
Each operating with a slightly different model of reality.
Which eventually collide.
In code.

Seen this way, tech debt is not a failure.
It's an expected side-effect.

Not a quality problem.
An alignment problem.
A coherence problem.

The reality of the code diverging from the reality of the organization.

TL;DR:
Fragmented realities. All the way down.

2. Delivery Pressure Breeds Incoherent Systems

Do you know the "Iron Triangle of Project Management"?
You don't?
Then you're one of today's lucky ten thousand.

Time. Cost. Scope.
Pick two.
(Management picks three.)

Teams don't have enough capacity to align.
Not on the problem space.
Not on the solution space.
Not even on what "done" means.

That leads to:
Leaky abstractions.
Unspoken assumptions.
Premature optimizations.
Fragmented realities.

You get software that works.
Most of the time.
Until reality disagrees.

Incoherent systems produce incoherent software.
This isn't accidental.
It's Conway's Law:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

TL;DR:
Delivery pressure biases systems towards fragmentation.

3. "Developmental (In)variants" in Code & (Nervous) Systems

Developmental (in)variant:
An intrinsic property of a system that constrains the possibility space of all future development.

There are primary (in)variants:
Change those, it's now a different system.
In Domain-Driven Design terms: core.

There are secondary (in)variants:
Change those, it's still the same system — but it behaves differently over time.
In Domain-Driven Design terms: supporting or generic.

In code:
Technology choices (e.g. database, language).
Architecture decisions (e.g. micro-services vs monolith).
Consistency guarantees (e.g. strict, eventual).

In humans:
Genetics (e.g. neurodivergence).
Background (e.g. beliefs, values).
Trauma (without going into that here).

To become coherent a system needs to explicitly accept its (in)variants.

By accepting them you enable integration.
By integrating them you enable informed, coherent decisions.
The alternative to integration?

In code:
Workarounds.
Brittle adapters.
Race conditions.
That one piece of code nobody touches.

In humans:
Conflict.
Avoidance.
Shutdown.
Masking.

Or in a nutshell:
Fight. Flight. Freeze. Fawn.

Not as pathology — as predictable system behavior under unmitigated load.

TL;DR:
You don't negotiate with "developmental (in)variants".
You integrate them.
Or you incur exploding complexity costs.

4. Fragmentation & Tech Debt: Stop Managing, Start Integrating

This leaves us with an uncomfortable conclusion:

Fragmentation manifests as tech debt.
Incoherent systems produce incoherent software.
Coherence requires accepting developmental (in)variants.

We won't resolve this by "building better solutions".
We resolve it by integrating conflicting models of reality.

In practice:

1. Accept divergent mental models as a primary (in)variant.
2. Align on problem space (objective facts).
3. Maintain system coherence under load (regulation).
4. Commit to coherent solutions (decisions).

What does failure look like?
Loss of coherence.
Overloaded systems produce fragmentation (incidents).
Regulation is about distributing load within capacity.
And leadership is a regulation function.
(Thank you, Miriam.)

5. Systemic Engineering: Maintaining Coherence Under Load

Tech debt isn't killing your product.
Unintegrated fragmentation from incoherent constraints is.

Human systems behave the same.

When load increases, unresolved conflicts don't disappear.
They get encoded.
In architecture.
In process.
In people.

Systemic Engineering is the discipline of making those conflicts explicit before they harden into structure.

Not by "communicating better".
But by designing constraints for coherence.
By surfacing conflicting models of reality.
By separating observation from interpretation.
By slowing decisions when alignment is missing.
By distributing load instead of dumping it downstream.

This is where trauma-aware leadership quietly shows up.
Not as therapy.
As capacity management.

A regulated system can stay coherent under load.
An unregulated one fragments.
In code.
In teams.
In people.
(I'm sorry, Cat.)

If this resonates, try this in your next retro:

• Where are we compensating instead of integrating?
• Which constraints are real, and which are inherited?
• What are we pretending is aligned when it isn't?
• Where is load accumulating without consent?

Navigating a legacy codebase.
Maintaining system regulation under load.
Neither is a tooling problem.
They're coherence problems.

Welcome to Systemic Engineering.
Where people's lived experience becomes part of the model.
And causality stops walking in straight lines.

6. Coherent Call-to-Action

Maintaining a legacy codebase?
Or leading an organization that keeps fragmenting under load?

This work can be done deliberately.

Systemic Engineering is how I help teams and leaders
restore coherence in complex systems.

You can reach me at:
📧 alex@systemic.engineer