Your Architecture Is Two Roman Horse Butts Wide

Modern railway gauge is allegedly the width of two Roman horses' rear ends. The story is mostly false — but the part that's true is the same force that's bankrupting your engineering org right now. A meditation on path dependence, sharpening the axe, and the migration that took five years because someone made a coin-toss decision in 2014.

Standard railway gauge is 4 feet 8.5 inches. According to a viral story that has been re-emailed, re-tweeted, and re-told for over a century, that number traces back to Roman war chariots — which were designed to be as wide as two horses' rear ends. The English copied the Romans, the Americans copied the English, and the Space Shuttle's solid rocket boosters were built in Utah and shipped through tunnels sized to that gauge. The boosters, the story goes, are therefore — transitively, unavoidably, gloriously — the width of two Roman horse butts.

It is a beautiful piece of folklore. Caesar designed NASA.

It is also almost entirely false. But the part that is true is the same force that is, right now, quietly bankrupting your engineering organization.

The myth, debunked, briefly

The Romans did not use war chariots. Chariot warfare was militarily obsolete in the Mediterranean by 600 BCE — centuries before Rome's expansion. The empire ran on infantry, cavalry, and the much less cinematic ox-drawn freight wagon. Roman cavalry horses, when archaeologists dig them up, turn out to have been pony-sized — about 14 hands at the withers, which is roughly the size of a stout modern Welsh Cob. Two of them flank-to-flank come to maybe 3 feet 8 inches. The horse-butt math doesn't even work.

The actual chain is shorter and less heroic:

• 1812, Northumberland. A 31-year-old engineer named George Stephenson takes a job at Killingworth Colliery and inherits a horse-drawn coal wagonway whose track happens to be 4 feet 8 inches wide.
• 1825. He uses that gauge for his first locomotives. The Stockton & Darlington opens at 4 feet 8 inches.
• 1830. On the Liverpool & Manchester, he moves each rail outward by a quarter inch to give the wheel flanges a little more lateral play. That's where the half-inch comes from.
• Forever after. Every railway in the world that uses standard gauge — which is most of them — is using a quarter-inch tweak applied to a coal-cart dimension that a guy in a Northumberland mining town didn't actually choose.

Robert Stephenson — George's son and the man who built half of British rail on top of his father's gauge — admitted later that "it would be difficult to give a good reason for the adoption of an odd measure." Even the people who set the standard knew the standard was an accident.

"It would be difficult to give a good reason for the adoption of an odd measure." — Robert Stephenson, on the gauge that now defines roughly 60% of the world's rail network.

The Roman chariot is the cinematic version. The actual mechanism is much more pedestrian, much more recent, and much more relevant to your codebase.

The Gauge War: a parable for every CTO who has ever lost a tech debate

In 1835, Isambard Kingdom Brunel chartered the Great Western Railway and built it to 7 feet ¼ inch — broad gauge. Wider, faster, smoother riding, more stable at speed. The Royal Commission on Railway Gauges sat from August to December 1845, ran comparative trials, and concluded that broad gauge was technically superior in essentially every dimension that mattered.

Broad gauge lost.

By the time the commission ruled, there were 1,901 miles of standard-gauge track in Britain and only 274 miles of broad. The Railway Regulation (Gauge) Act of 1846 mandated 4 feet 8.5 inches for all new lines in Great Britain. The better engineering was outvoted by the worse engineering's installed mileage.

This is not a footnote. This is the entire shape of technical debt.

The cost of changing a standard scales with how many miles of it you've already laid. Not with how wrong it was to begin with. The cost of staying scales with the same thing — every dependency you build on top of a foundation increases the cost of changing that foundation later. The two curves diverge over time, and at some point they cross a line where it is permanently cheaper to live with the worse choice than to fix it.

That line, in software, is where most production systems live.

What this looks like in your codebase

The "small" early decision: a database, an ORM, a serialization format, a cloud provider, an auth scheme, a Python version, an event bus. Made when the company was four engineers in a room, optimizing for the constraints they had — which were almost always "ship something that works by Friday."

That decision is fine. The problem is what comes next.

Every line of code written after the decision is a vote to keep it. Every dashboard that queries the database, every report built on the schema, every onboarding doc that explains "the way we do it," every analyst who's spent three years getting good at the query dialect, every batch job that runs at 4 AM — all of it is path dependence accumulating. You are not laying track. You are paying interest.

Your stack is not a decision. It is a sediment layer. And like real sediment, you only notice it when something tries to dig through.

Frost: a real war story

I'll name a real one. Frost Weather Solutions runs a real-time weather monitoring platform for snow removal teams. When DRYCodeWorks engaged with them in 2023, the database of record was Microsoft SQL Server — a defensible 2014-era choice for what Frost was at the time, which was a much smaller, much simpler operation.

By 2023 the math had completely changed. The platform was choking under seasonal load. API responses had degraded to a 12-second average. Customers were dispatching snowplows on dashboards that updated slower than the storms moved. The SQL Server choice that had been correct in 2014 was no longer correct in 2023. The full case study is here if you want the play-by-play: How we rescued Frost's weather platform from performance paralysis.

Here is the part that matters for this argument.

We did not migrate off SQL Server. I want you to sit with that for a moment, because it cuts against the obvious story. We brought in ClickHouse Cloud for high-performance time-series analysis. We brought in ElastiCache for image packets and MemoryDB for ephemeral forecasts. We rebuilt the data flow as event-driven through SQS, EventBridge Pipes, and Kinesis. The platform went from 12-second responses to 150 milliseconds — an 80× improvement — and customer retention through an ownership change hit 98%.

But SQL Server is still there. It is still the database of record. It will probably still be the database of record in five years.

"While we maintained SQL Server as the database of record (migrating would have been too risky given the timeline), we strategically offloaded specific workloads to specialized services." — from the Frost case study.

That sentence is the most honest description of path dependence in production engineering you will read this week. The original choice was not wrong enough to be worth removing. The cost of removing it had grown faster than the cost of keeping it, even as the cost of keeping it was real and visible. So we built a second system around the first one, treated the old gauge as a constraint rather than a target, and routed the new traffic to better infrastructure.

That is what victory in a Gauge War looks like in 2026. You don't change the gauge. You build a parallel network that shares track where it has to and diverges where it can.

Sharpening the axe

There is a quote, probably apocryphal, attributed to Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."

Most engineering organizations do the opposite. They spend six hours chopping, then wonder why every cut takes longer than the last. The axe is dull because it was sharpened in 2014 — for a tree that doesn't exist anymore.

"Sharpening the axe," in the modern engineering sense, means revisiting your foundational choices before the cost of changing them outpaces the cost of keeping them. It is unglamorous work. It does not ship features. It does not photograph well in a sprint demo. And it is the only thing that keeps you shippable in five years.

A practical version of this discipline:

• Every quarter, name one architectural choice you would not make again today. Out loud, in writing, with at least one engineer and one person who feels the cost.
• For each named choice, estimate two numbers: the cost of migrating now, and the projected cost of keeping it for another year. Be honest about both.
• When the second number exceeds the first, stop adding dependencies to it. You don't have to migrate today. But you should stop building tomorrow on a foundation you've decided to leave.
• When you can't even name the choice — when the foundation is so embedded that no one remembers it was a choice — that's the one that's going to cost you the most.

The twist nobody wants to hear

Here is the part that should bother you.

The competitor who started two years after you has two years less code, two years fewer ratifications baked in, two years fewer dashboards built on the schema you wish you hadn't picked. They get to choose a sharper axe. They get to skip the gauge debate entirely because they have only laid 274 miles of track instead of your 1,901.

You don't get to opt out of path dependence. You only get to pick how aware you are of it — and how often you are willing to stop and re-sharpen while your competitors are out there chopping.

The standard gauge of your architecture was set by some constraint that no longer applies, by someone who probably isn't in the room anymore, for reasons that may or may not have been good even at the time. You inherited it. You ratified it every day you didn't change it. And every line of code you write today is, in some small way, a 19th-century coal cart for the people who will be maintaining your system in 2034.

Pick your gauge carefully. And every once in a while, put down the axe and sharpen it.