DEV Community

Cover image for Git Archaeology #11 — Entropy: The Universe Always Tends Toward Disorder
machu
machu

Posted on

Git Archaeology #11 — Entropy: The Universe Always Tends Toward Disorder

Entropy always increases. Engineers fight it.

Entropy — ordered blocks decay into disorder

Previously

In Chapter 10, I wrote about Dark Matter — work that doesn't appear in commits, invisible gravity.

This time, I write about another law of the universe.

The Second Law of Thermodynamics. The increase of entropy.


Entropy

Physics has a concept called entropy.

Put simply — order, left alone, always breaks down.

Drop a single drop of ink into a glass of water. The ink diffuses and mixes uniformly. But the reverse never happens. Ink never spontaneously separates from the mixed water.

This is the increase of entropy.

The universe always tends toward disorder. Maintaining order requires energy.


The Entropy of Code

Codebases have entropy too.

Left alone, code always rots.

At first, the design was beautiful. Layers were clear, responsibilities separated, naming conventions unified.

Six months later —

  • "It's urgent" — a shortcut cuts through layers
  • "Just this one place" — a method ignores the naming convention
  • "It works for now" — code goes in without tests

This is the entropy increase of code.

Each one is small. But accumulated, the structure crumbles.


Entropy and EIS

EIS's five score axes are deeply connected to entropy.

Production — An Act That Increases Entropy

Writing new code increases entropy.

More code means more complexity. More dependencies. More to understand.

Production is necessary. But Production alone drives the universe toward chaos.

Quality — An Act That Resists Entropy

Writing tests. Making review comments. Fixing bugs.

These are acts of resisting entropy.

Engineers with high Quality scores are guardians of the universe's order.

Survival — Proof of Victory Over Entropy

Code has survived for a long time. Meaning it endured the pressure of entropy.

Survival 100 is proof that "this code was not eroded by disorder for six months."

Design — The Greatest Weapon Against Entropy

Design is the most powerful weapon against entropy.

Good design limits the blast radius of changes. Module boundaries are walls that block the propagation of entropy.

Architects with high Design scores are people who build entropy barriers.

Breadth — The Monitoring Range of Entropy

Engineers who touch a wide range can detect signs of entropy early.

"This area is starting to rot" — engineers with high Breadth can sense the health of the entire universe.


The Battle Against Entropy

Software development is, at its core, a battle against entropy.

Every new feature increases entropy. Refactoring is the act of reducing entropy. Tests are sensors that detect entropy increase.

Watch a team's score trends and you see the results of the battle against entropy.

  • Quality scores declining → entropy is winning
  • Survival declining → past order is crumbling
  • Design scores rising → barriers are being reinforced

EIS timelines are the record of a battle against entropy.


Why Refactoring Is Necessary

"Don't touch working code."

This is a common engineering maxim.

But physics teaches us something different.

Left alone, order always breaks down.

If you don't touch working code, as the surrounding code changes, order degrades relatively.

Refactoring is the act of locally reducing entropy.

As I wrote in Chapter 10, small refactors look like "dark matter." They don't stand out in commit logs.

But they're holding back the collapse of the universe.


Entropy Cannot Be Avoided

Finally, one harsh truth.

The increase of entropy cannot be avoided.

No matter how beautiful the design, no matter how excellent the team, entropy will inevitably increase over time.

Perfect order doesn't exist. A perfect codebase doesn't exist.

What exists is — only the will to keep fighting entropy.

A good engineering team is one that keeps slowing the rate of entropy increase.

EIS tells you where you stand in that battle.


Series

EIS — the Git Telescope

GitHub: engineering-impact-score — CLI tool, formulas, and methodology all open source. brew tap machuz/tap && brew install eis to install.

If this was useful: ❤️ Sponsor on GitHub


Chapter 10: Dark Matter | Chapter 12: Collapse →

Top comments (0)