Software Laws from First Principles — the story behind the series
The thought experiment: rebuilding communication from first principles, one constraint at a time.
I did something backwards. Instead of opening a networking course and memorizing what TCP and IP and DNS are.
I started my thought experiment in the year 1800 — before any of it existed — and tried to invent the internet myself, one forced decision at a time. Every time I proposed a solution, it broke under the next problem. And every time it broke, I was accidentally rediscovering an idea that real engineers spent decades arriving at.
This post is the map of that journey. It's also the premise of everything else I'm writing: I don't want to learn what humanity invented. I want to put myself in the position where the invention becomes inevitable — and then compare my version to the real one. That's the whole series.
Here's how it went, mistakes included.
It didn't start with computers. It started with distance.
Strip away all the technology and communication is just this: someone has information, someone else needs it, and something in between has to carry it. Smoke signals, letters, telephones, WhatsApp — same system, different transport. The enemy was never "not having a phone." The enemy was distance, and everything after is a fight against the delay distance creates.
Communication begins with a simple problem: getting information across distance.
So I started with nothing. A messenger on a horse. Information moves only as fast as a physical object. Then the telegraph arrives and, for the first time in history, humans separate the message from the messenger — the information moves without a physical thing carrying it the whole way. That separation turns out to be one of the biggest moves in the entire story, and it keeps coming back.
Then I had to connect more than two computers — and it fell apart fast
Two computers, one wire. Fine. Then a third, a fourth, a thousand. I got asked a deceptively simple question: to connect 1,000 computers so each can reach every other, how many wires do you need? I didn't calculate it — I just felt it. It explodes. It doesn't scale.
Connecting more machines makes the network harder to scale—and exposes the limits of direct connections.
So I proposed a central hub. Everything routes through one machine. Clean. And immediately I'd walked into my first trap: the single point of failure. Destroy the hub and the entire network dies. A king, a CEO, a database, a data center — great architects fear the thing that takes everything down when it falls.
A centralized network is simple to build, but one failed hub can bring everything down.
That fear is exactly what drove the real design. The Cold War military didn't ask "how do we connect computers?" They asked "if a city is destroyed, should the network survive?" The old telephone system said no. The answer had to be yes. That single requirement bent the entire architecture.
Where I started sounding like a government (and why that was a problem)
I noticed my own instinct. Every time a problem appeared, I invented a master — a controller, a manager, a central registry that knows everything. That's how governments and corporations organize. So the guide kept attacking it: who manages the master? Who manages the backup of the master? How many updates per second can one master process before it becomes the bottleneck?
That's when the real shift happened. I stopped asking "who should be in charge of this?" and started asking "can this organize itself?" Ant colonies work and no ant knows the whole colony. Traffic, markets, languages — none has a central controller, and they all function. I moved from central control to local rules, and it turns out that's one of the biggest mindset changes in all of software architecture: local knowledge scales better than global knowledge.
Removing the single point of failure means allowing the network to route around problems.
The mistakes I made along the way (these are the good part)
I want to keep these in, because the polished version of this story would hide them and the polished version is worthless.
I assumed the bottleneck is always the medium — the wire, the road, the transport. Wrong. The sender can be the bottleneck. So can the receiver, the storage, the trust, the cost. Most technology isn't solving a transport problem at all.
I kept adding metadata to every message — address, order, status, security, retries, checks — until the guide asked: should a two-character message carry the same baggage as a 1GB file? At some point the information about the message gets bigger than the message. Every solution creates new information that itself has to be managed.
I tried to build a master that knows everything, repeatedly, before finally accepting no such machine can exist at scale.
Each wrong answer wasn't a failure. It was the exact wrong turn the industry itself took before correcting. Making the mistake is how you understand why the correction mattered.
The moment it stopped being about wires
Late in the journey the guide asked what I was really building — a network, or something else. And the answer that came out was: a set of rules that lets strangers communicate. Not wires. Rules.
That reframed everything. The real invention wasn't the internet. It was the agreement — the protocol — that lets independent systems that know nothing about each other still cooperate.
The machines can be independent; the rules are what allow them to communicate.
That's the idea behind internetworking: independent networks connected by a common set of protocols.
The rules matter more than the machines.
And rules, it turns out, are what survive. The internet isn't wires; it's protocols. React isn't components; it's principles about UI. Docker isn't containers; it's a principle about packaging environments. The implementation dies. The contract lives.
The laws I walked out with
By the end I hadn't memorized networking. I'd collected a set of engineering laws that keep reappearing far outside networking — in databases, cloud, React, Kubernetes, even in how companies are structured:
*Purpose before mechanism *— ask why it exists before how it works.
Constraints create innovation — no constraint, no invention.
Every solution is a tradeoff — there's no perfect architecture, only chosen pains.
Shared resources beat dedicated ones when demand is intermittent (this is why we share roads, CPUs, and cloud servers instead of building private ones per user).
-** Local knowledge scales better than global knowledge.**
Overload has only four responses: wait, distribute, add capacity, or reduce demand. There is no fifth.
Bottlenecks move; they don't disappear. Solve one and it reappears somewhere else.
Every responsibility has a natural home — a system should do only what only it can do.
Communication is transferring a mental model, not words — meaning comes from shared reality, not vocabulary.
Isolate what changes fast from what changes slowly — this is why layers exist.
Stable contracts enable independent evolution — protect the agreement, not the implementation.
Identity ≠ Location — who you are and where to reach you are two different things, and confusing them breaks systems the moment anything moves.
Each of those is its own post in this series. This is the map; the rest are the territory.
Why I'm doing it this way
Most people learn technology by accepting the invention. I'm questioning the necessity of the invention. When you can see the problem before the solution, the technology stops being something to memorize and becomes something you'd have built yourself.
The catch — and I'll be honest about it — is that all of this stays theoretical unless it ends in something real. So every cycle of this series ends with building, publishing, or shipping. Understanding without building is just a more sophisticated way of collecting tools.
Next in the series: Identity ≠ Location — the distinction I got wrong at first, and the reason DNS, Kubernetes Services, and your phone's contact list all quietly work the same way.
