Knowing When Not to Compress
Domain-Specific Encoding
Knowing When Not to Compress
I've spent three posts building an argument:
- Shop floor pidgins compress decades of knowledge into a few syllables
- Codebases develop the same dynamics
- CAD systems encode compression choices in their very structure
The throughline: compression is everywhere, it's never purely technical, and it depends on shared context between humans.
But I've been describing compression as something that happens to you. Pidgins evolve. Codebases accumulate jargon. CAD libraries drift. What if we did it on purpose?
And if we could — should we?
The Lifecycle
Watch any team long enough:
Phase 1: Explicit. Everything spelled out. New team, new codebase, new product line. Nobody shares context. Communication is verbose. Separate files. Long names. Full sentences.
Phase 2: Compression. Patterns emerge. People get tired of repeating themselves. Shorthand develops. Abstractions appear. "Just use the standard approach" starts to mean something. Efficiency climbs.
Phase 3: Over-compression. The shorthand accretes. Layers pile up. New people can't parse it. The configuration system has configurations. One person knows the incantations. Everyone else works around them. Efficiency collapses.
Phase 4: Crisis. An expert leaves. A miscommunication cascades. A project fails. Someone intervenes. Complexity gets pruned. Documentation gets written. The cycle restarts.
This isn't failure. It's how living systems work. Compression naturally tends toward over-compression until reality pushes back. The only question is how hard reality has to push before you listen.
Anti-Fragile Compression
A fragile compression scheme breaks under pressure. One expert leaves, the whole system goes opaque.
A robust scheme survives pressure. Redundancy, documentation, fallbacks. It doesn't improve, but it doesn't collapse.
An anti-fragile scheme uses pressure to evolve. Each miscommunication reveals a boundary that was assumed but not shared. Each failure exposes compression that went too far. The system learns from its own breakdowns.
The teams that do this well share a trait: they treat communication failures as data, not just problems. When someone doesn't understand, that's information about the codebook. When a configuration trips someone up, that's a signal about compression level.
They're not preventing friction. They're using friction to calibrate.
The Meta-Skill
The highest-leverage skill isn't compression or expansion. It's knowing which one to use.
Compress when the pattern genuinely repeats, the audience shares the codebook, the boundary is stable, and speed matters more than onboarding.
Expand when the audience is mixed, the concept is evolving, the stakes of miscommunication are high, or you're crossing a boundary between teams.
The best communicators I know — engineers, fabricators, managers — do this without thinking. Dense jargon with insiders. Explicit language with outsiders. Complex configs for stable patterns. Separate files for contested boundaries. They've internalized not just the pidgin but the meta-knowledge of when to deploy it.
Can You Design a Pidgin?
Christopher Alexander tried. His Pattern Language was a deliberate compression scheme for architecture — named patterns encoding solutions to recurring problems. "Light on Two Sides of Every Room." "Intimacy Gradient." "Street Cafe."
Each pattern is jargon: a few words that unpack into pages of reasoning. Architects who share the vocabulary communicate densely. The pattern names become shorthand.
But the pattern language only works if you learn it. Alexander wrote 1,171 pages to define the codebook. The compression requires massive upfront investment.
This is the fundamental tradeoff:
- Evolved pidgins have low upfront cost, high maintenance cost. They drift, fork, lose speakers.
- Designed pidgins have high upfront cost, potentially lower maintenance. They can be documented, taught, versioned.
Most real systems end up as hybrids. A designed core — official terms, architectural patterns, standard configs — surrounded by evolved accretions. Local jargon. Workarounds. Tribal knowledge growing in the gaps between the formal structures.
The question isn't designed vs. evolved. It's how much of each, and where the boundary falls.
And that boundary? That's the interesting part. That's where the designed system meets the emergent one. Where the specification meets reality. Where the engineering drawing meets the shop floor.
That boundary has a name. But that's another post.
The series: Wing Plates and Head Frames | Your Codebase Is a Pidgin | The CAD File Is a Pidgin Too | Knowing When Not to Compress