Tools: Powerful Complexity Can't Be Eliminated. It Can Only Be Moved.

Posted on Jan 23

• Originally published at itnext.io

Cover Image Photo by Sunder Muthukumaran on Unsplash

A senior engineer made our API faster by caching responses. Query time dropped 80%. We celebrated.

Two months later, the cache was stale. Data was wrong. Users complained. We spent weeks debugging cache invalidation.

The speed didn't come from nowhere. The complexity didn't disappear. We just moved it.

This pattern behaves like a conservation law from physics. Not perfectly, but close enough to be useful.

In physics, certain quantities can't be created or destroyed. Only transformed or moved. Energy conservation says energy can't be created or destroyed, only converted (chemical to kinetic, kinetic to heat). Momentum conservation says total momentum stays constant in a closed system. Mass conservation says mass doesn't appear or disappear, just rearranges.

These aren't guidelines. They're laws. You can't violate them. You can only work within them.

Software has something similar: essential complexity (the inherent difficulty your problem requires) can only move, not disappear. Larry Tesler famously called it "Conservation of Complexity": complexity can't be eliminated, only moved. UX designers know Tesler's Law intimately. But while this principle is well-recognized in design circles, software architects rarely discuss it explicitly or apply it systematically.

I've noticed we treat "simplification" as if we're eliminating complexity rather than relocating it. We don't measure both sides of the trade. We don't name what's actually being relocated.

Source: Dev.to