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

Source: Dev.to

The Second Law of Thermodynamics

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, and the reverse never happens. This is the increase of entropy. The universe always tends toward disorder, and maintaining order requires energy.

Entropy in Codebases

Code, like the physical world, has entropy. 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.

Each change is small, but accumulated they crumble the structure. Writing new code increases entropy: more code means more complexity, more dependencies, more to understand. Production alone drives the universe toward chaos.

Resisting Entropy

Acts that resist entropy include:

• Writing tests.
• Making review comments.
• Fixing bugs.

Engineers with high Quality scores are guardians of order. Code that survives for a long time proves it has withstood entropy’s pressure. A Survival score of 100 shows that “this code was not eroded by disorder for six months.”

Design as an Entropy Barrier

Good design limits the blast radius of changes. Module boundaries act as walls that block the propagation of entropy. Architects with high Design scores build these barriers. Engineers with broad Breadth can sense when “this area is starting to rot,” detecting entropy early across the codebase.

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

• Every new feature increases entropy.
• Refactoring reduces entropy.
• Tests are sensors that detect entropy increase.

Watching a team’s score trends reveals the battle’s outcome:

Refactoring and “Dark Matter”

The maxim “Don’t touch working code” clashes with physics: left alone, order degrades as surrounding code changes. Refactoring locally reduces entropy. Small refactors, like “dark matter,” don’t stand out in commit logs but hold back the collapse of the universe.

The Harsh Truth

The increase of entropy cannot be avoided. No matter how beautiful the design or how excellent the team, entropy will inevitably increase over time. Perfect order—and a perfect codebase—does not exist. What exists is the will to keep fighting entropy. A good engineering team slows the rate of entropy increase, and EIS tells you where you stand in that battle.

Related Chapters

1. Measuring Engineering Impact from Git History Alone
2. Beyond Individual Scores: Measuring Team Health from Git History
3. Two Paths to Architect: How Engineers Evolve Differently
4. Backend Architects Converge: The Sacred Work of Laying Souls to Rest
5. Timeline: Scores Don’t Lie, and They Capture Hesitation Too
6. Teams Evolve: The Laws of Organization Revealed by Timelines
7. Observing the Universe of Code
8. Engineering Relativity: Why the Same Engineer Gets Different Scores
9. Origin: The Big Bang of Code Universes
10. Dark Matter: The Invisible Gravity
11. Entropy: The Universe Always Tends Toward Disorder (this post)
12. Collapse: Good Architects and Black Hole Engineers
13. Cosmology of Code

Tools

• GitHub: engineering-impact-score – CLI tool, formulas, and methodology are open source.

  brew tap machuz/tap && brew install eis

If this was useful, consider exploring the other chapters for deeper insights.