Ryan Koch (00:22)
What does the minutia nineteenth century train track gauges have in common with the challenges of modern data infrastructure? Other than both being intensely nerdy and interesting, more than you'd think. In eighteen fifty three, workers at a railroad junction in Erie, Pennsylvania built a complex transfer system, unlitting cargo from one set of tracks onto another. Quite a profitable operation. But it sounds like a logistical nightmare, right? Why would they take on

such a difficult task. They had to deal with a mismatch in the tracks. A passenger heading from Buffalo to Cleveland had to change trains twice, once at the New York border, once in Erie. The trains were timed to connect, but delays were common, connections were missed, and travelers found themselves unexpectedly stranded overnight in Erie. Journey upon journey, thousands of transfers stacking up over years, all that effort

All that friction without ever addressing the core issue. The tracks. Consider a brittle web scraping pipeline. It silently fails on a Wednesday. Perhaps a neat CSS selector changed. A feature request went through, a designer made a shift, a developer wrote some code, a deploy landed, a ticket closes on a Tuesday. Thursday comes, and so do notification bubbles. One ticket closed there, but elsewhere, an eruption of new ones.

Those of you out there that have worked on a web scraper, an ETL pipeline, or some other go-between process for government sources can probably relate to that.

Let's talk a little train history. In by 1871, there were at least 23 different gauges in use by American railroads. Don't worry, I'm not going to info dump all of those on you, but there are a few that are worth mentioning. There's the four foot eight and a half inch Stevenson gauge, which was used by most northern and western railroads. This one is interesting because it originated in England, where George Stevenson built the first commercially viable steam locomotive.

One account is that he came up with this measurement based on the width of coal wagons of the time, with an additional accounting for two inch wheels and what I'll call a fudge factor. Another account comes from a gauge of a similar width at four foot eight inches, which is being used for the Stockton and Darlington railway. Stevenson was involved in that effort by their request, so it would be reasonable to assume that the experience would influence him later.

When he designed the Liverpool and Manchester Railway, he would land on that four foot eight and a half inches. Since the difference was small, those two lines were able to operate with the same cars without safety concerns. The gauge would eventually become the standard there in the mid eighteen forties through an act of parliament. Since England was the place where the railroad game started, it naturally became a spot where folks went in order to study the industry.

As you might imagine, Americans studying railroad construction there would then come home with a bias towards that Stevenson gauge. As a result, the first steam powered railroad in the state of New York, the Mohawk and Hudson, used it as it opened for business in 1831. There was also the five foot gauge, which was dominant across the southern United States. In 1827, Horatio Allen, chief engineer of the South Carolina Canal and Railroad Company, had prescribed its use.

As you likely know, those states' economies at the time were heavily invested into cotton and its transport. This width was seen as most efficient for carrying those sorts of bales. And there was the six foot Erie gauge. It came to be when New York and Erie Railroad was chartered in 1832 and opened in 1841. Its supporters asserted the wider gauge was future proofing for larger and longer trains as they blindly become busier over time. And they also viewed it as being a more stable width.

That railroad would use this to connect a regional network throughout New York State, which would eventually connect to other lines, expanding its reach from the Hudson River to the shores of Lake Erie. And of course, I have to mention the 5 foot, 2.5 inch gauge, since I grew up in Cincinnati. This was an example of a local rail gauge used for things like streetcars and light rail. In Cincinnati from 1859 to 1951, this is what the streetcars ran on.

Other examples of use are in New Orleans, Philadelphia, Pittsburgh, among others. There's probably as many reasons for these different gauges as there are gauges themselves, but there's three reasons I'd ask you to keep in mind as we talk about this. Different places traded different goods, and lacking another thing to optimize for, they went for the use case that made the money. We mentioned cotton when talking about the five foot gauge, but talked about coal when talking about Stevenson.

It's rational for regional networks to trend this way. Engineering opinions also matter. We covered the belief of those behind the six foot ERI gauge that it would provide greater stability and capacity for larger and longer trains. Often engineers leading these projects would have to weigh use cases, and where they landed had a large influence on the line. It doesn't sound perhaps so different than what happens with decisions in a software stack. With those pressures, there was none from above.

the local or regional level to create an alternative incentive. And without an authority forcing it one way or another, local concerns were left to conduct their own affairs. Okay, yeah, I I mean an apology for that one.

We all know that standardization is better in these situations, but no individual player can unilaterally convert and win. They take on all the cost, but the benefit would be shared, and so nobody moves. This is what we call a coordination trap, where with incomplete information, all the players of this economic game wind up making decisions that optimize for their own individual interest.

They miss out on opportunities to cooperate with others to benefit even more. If there were some way to close that information gap and provide some assurance, then perhaps the game gets played differently. If all the players know that a particular standard will be used and that all other players will go along with it, then the cooperation choice, yielding the greater benefit, is an easier one to make. Of course, as I talk about standards, my brain immediately jumps to an old webcomic.

XKCD by Rondell Monroe. There's one called standards, which lays out a situation where there's 14 competing standards. Our protagonist believes that's ridiculous, and that a new universal standard should be made to cover everyone's use cases. It then closes with a situation where there are 15 competing standards. Whether it's USB chargers, railroad tracks, technology changes, but that joke remains relevant.

Randall Monroe could have drawn that in twenty eleven about USB, he could have drawn it in eighteen fifty three about railroad gauges, or last week about state public records APIs.

Now, imagine sitting down at your laptop and opening a state database portal. You might be greeted with some ASP.NET forms, session based navigation, hidden form fields, and or a JavaScript heavy single page kind of thing. There's a lot of possibilities. As you read through the dataset and start to get a feel for how useful it could be for your work, you start to see inconsistencies in data shape. You compare with another state,

And find that they have a completely different idea about what a business status means. One state calls it active, another in existence, a third, good standing. Perhaps they have all that codified in law or regulation from an agency, so that's how the software represents it. And then you remember APIs are a thing. Maybe I don't need to interact with this front end bit. And so you go explore over there, and you find that it too is all over the place.

technology, you know, keeps on changing, but often the incentive structures don't.

In places where gauges changed, like Erie, Pennsylvania, machines, systems, and logistics were all necessary to make sure the cargo and passengers could swap from one train to another. Sometimes this involved creating large, steam powered hoisting machines. These could lift heavy loads, or even a whole train car onto the next gauge's rolling stock. In theory, folks designed this stuff to avoid delays or harsh conditions, but sometimes reality decided differently.

As the Erie War escalated in eighteen fifty three and tracks were torn up, Horace Greeley, a famous New York newspaper editor of the day, described rail passengers walking seven miles from Harbor Creek to Erie in the snow.

A lot of folks out there working on technical projects have found themselves having to build their own hoisting machine equivalents. In my case, discovering that storing and serving information on licensed childcare providers has as many solutions as there are states. As you might imagine, the ease of that access for these varies depending on which one you're talking about. And so I did what anyone might do and started trying to build a set of web scrapers to try to automate.

you know, bringing that data together. You know, so coworkers, researchers, or just curious people could do something with it. As I wrote this episode, that effort had gotten to about forty states plus DC put together to a place where it's regularly pushing to an open repository. There are a few rough buckets of c or categories of these that I've found along the way. Thirteen of them had some kind of JSON or REST API I could hit.

Using little more than just the scrapey Python library. Those were the nice ones to build against. I haven't run into a ton of major breaking changes with API endpoints or the contract changing, but that ultimately remains a risk with this type. Nine of them have involved just scraping HTML content, but that's still mostly just using the scrapey library. These are a little more fragile and a bit more tedious to maintain, but they're not actively fighting the effort.

The usual thing that causes a problem is some sort of structural HTML change to how they're presenting the data and needing to then kind of revisit to figure that out. Seven have been single page applications without an easy API to hit. As you can see, we're starting to creep up that difficulty slash annoyance curve, as these now introduce using a tool like Playwright to simulate a browser. This becomes necessary usually because some component of the page requires JavaScript functionality to work.

and get at the data. These situations add another layer of fragility where rendering performance can start to create time matters that you have to bounce back from. And this has the same issue as the previous HTML example, where structural changes to how things are presented can also break the flow. The last eight have also been easier situations, where they're running something like Salesforce Aura, Socrata, or just a straight CSV download. These situations are a matter of hitting an API endpoint and parsing whatever comes out.

And if you're counting, you might go, Ryan, that's 37 of the 41 you mentioned. But that's because four of these I had kind of in progress as this was going, so they didn't end up in a category. Sometimes fun problems come up as you're doing this sort of work. For example, in my case, some states will throw a capcha at you if you can't manage to get a browser simulation score that rises to an appropriate level. There's one state, I won't name them bada. It's but it was a weekly thing for a while.

Or you know even had like make sure that my egress point for my web traffic was had a reputation that was strong enough to work. Of course, I'm also not trying to be a jerk as I do this stuff. You know, you need to start building a reasonable intuition for what a reasonable rate of concurrency is while you're scraping. You don't want it to take years to get your data, but you also don't want to put load on a serv too much load on a service that people need. At some point I could probably do an episode all about just the travails of maintaining a web scraper in one's free time.

But the point is it's not irrational for us to end up with fifty different solutions to a problem like this. You can imagine that each state is playing a coordination game, where they can choose to focus on their own platform or seek to cooperate with others. The politics, funding, and requirements would all seem to push toward a Nash equilibrium where everyone focuses on their own platform. A Nash equilibrium is a situation where no player can gain by changing their strategy alone.

Here, the first day to try cooperating absorbs the cost, the risk, while only gaining benefit if others join. That imbalance pushes them away from the play. For theory nerds, what I'm describing is similar to a stag hunt. Imagine there's two hunters, and the only way they can get a stag is by working together. Or they could go out and get a hare alone. The risk is that they don't know what the other hunter will decide to do. If one chooses stag, while the other chooses hare,

While the first one is out of luck. That risk creates a perceived cost that pushes both hunters towards push choosing hair, which at least guarantees some food. This happens even though they'd gain more food overall if they worked together and got that stag. Ironically, projects like mine and others that seek to act as a band-aid, bringing data together, act to reinforce some of these incentives. If there's a workaround, there's fewer potential sources of pressure, fewer sources of pain, to change the incentives.

If you've ever written a scraper and thought this is ridiculous, there should be an API for this, well, congratulations. You've built a nineteenth century hoisting machine in computing and felt the absurdity that some of those workers in a place like Erie might have felt.

Mentally heading back to Erie, the situation there created an entire economic setup around transfer friction. That that that that friction we've talked about. There were workers moving the cargo, hotels where folks stayed when they got stranded, vendors selling their wares, and restaurants keeping folks fed. It's easy to see how there would be tension about losing all these opportunities to make a living off the situation. And so the effort to standardize became a threat to all those

folks.

Leading to a thing we've referred to as the Erie Gauge War. From late 1853 into 1854, citizens tore up tracks, burned a bridge, and even attacked railroad crews. On december seventh, eighteen fifty-three, Alfred King, Merriviri, swore in special police constables, 150 of them, and took part in the conflict, cutting out bridge sections. An action in similar spirit also happened in Harbor Creek, just seven miles away, where they tore up tracks along the highway. The back and forth continued.

The fight between laying track and ripping it out. On December 27, 1853, an official shot a man in a crowd, which by a stroke of luck just knocked him unconscious. The crowd thought he died though, so they chased after the official, and with a couple of those members managing to get onto the train he escaped to. And so as you might guess, that train reversed course and got the heck out of there at that point. February first, eighteen fifty-four saw the railroad finally make it through Erie without change.

And though disruptions continued through eighteen fifty six, with assaults, fires, and even the teardown of a newspaper building, it's said that the subject was taboo there for years after all these events happened. This wasn't a bunch of irrational actors seeking chaos. These are people whose livelihoods depended on that spot of friction. Standardization became an existential threat to them. In our times, we have our own systems that go don't quite link up. One example that comes to mind is in healthcare.

Epic Systems controls health information for up to 94% of Americans, according to allegations made by Particle Health in a legal dispute between the two of them. The 21st Century Cures Act, signed into law on December 13th, 2016, set up a legal framework for the exchange of data through health information technology systems. It's a legal mandate for interoperability. Epic, the big player in this space,

Is often a target of accusations that it acts in an anti-competitive way, despite this mandate. On paper, they appear to comply with the law and what it asks of them, but in practice there's more nuance. In Particle Health v Epic, filed September of 2018, the allegation was made that API-based access to patient data was blocked, hospitals were steered towards Epic's own payment platform, and that they interfered with the care quality health information exchange. In

Cure IS Healthcare, v Epic, it's alleged that an Epic first policy pushed customers toward Epic's own modules, tactics like denials and delays to API access being potentially in the mix. Just this past month, as I wrote this, the FTC opened an antitrust probe investigating whether Epic used non compete agreements and its dominant market position to block rivals from accessing patient data. Texas Attorney General Ken Paxton sued December of

2025, alleging that the company is shutting out would-be rivals by holding data hostage, using restrictions and fees as levers to do that. And it isn't just epic to worry about in this situation. The 21st Century Cures Act that we mentioned earlier also directed the ONC, the Office of the National Coordinator for Health, Information Technology, that is a mouthful. They were directed to create a standardized process for the public to report claims of the sort of

information blocking that's scattered in these allegations. So far, as of July, they've received two thousand five hundred and sixty three submissions, of which two thousand four hundred and fifty were claims of blocking. To avoid putting too much sensationalism on that though, those claims are not necessarily indicative of an investigation having happened, with the result that confirms that there was blocking behavior. That said, the volume still seems troubling.

One might want to consider this like a prisoner's dilemma game, but that implies equal power balance. Economists have another term, the holdup problem, which might be more accurate. Hospitals have made large investments into their Epic deployments perhaps years ago. It's not something that's easy to undo. And so there's an opportunity for Epic to extract a toll. Erie was the place where you had to switch trains. ECPIC becomes the place where you have to go for data exchange.

And while we do have the Cures Act, a sort of compliance theater could prevent it from having the desired effect. The rule can measure that an API is there, but it's harder to validate that it delivers something useful. And so you can imagine in a market leader's shoes that you might put your energy into making sure the easy to verify things are there and a little less energy and a little less energy into the others. Technically you're compliant, even if you're still profiting off friction. If you fit an API that responds with a 200 okay,

But gives nothing useful, then you know about the gap we're talking about. It's the difference between a track that ends in Erie and one that manages to go through without a change. Not all these stories are tales of woe and inconvenience. Sometimes incentives line up and folks actually do, the most beneficial thing. In February of eighteen eighty six, leadership for the southern United States major railroads met at the Kimball House in Atlanta, where they voted to adopt a narrower gauge.

You might recall from before that up to this point, the dominant gauge in the South had been five feet. This group consisted of 70 officials from 30 lines, they received advice from numerous heads of transportation and maintenance of way departments, among others, and decided to change all of the South's main lines over two days. Granted, they chose four foot nine inches as their gauge, which is a half inch off from the Stevenson gauge, but close enough to be compatible.

This rhymes in a fun way with Stevenson Gage's own story earlier in our discussion with the half inch difference. Those two days were planned for the change, were planned to be May 31st through June 1st of the same year. Work crews of 26 men were each recruited, with each member given a specific role, moving rails, spiking, car shoving, water carrying, and more. Workers were paid $1.50 a day and were provided meals.

And so in two days, some eleven thousand five hundred miles of rail moved inward. It was possible to achieve this by moving only one side of the rail, so it was decided that the western or northern side of each track would shift the three inches. Since there were four months of preparation time before the work started, it was possible to develop special wheels that could be rotated to support the new gauge the day the tracks reopened. There wasn't a mandate from Washington. Instead it was a

The pressure of being isolated from the rest of the country, and its rail lines that acted as the impetus for this change. With the Illinois Central and the Mobile and Ohio Railroad switching to standard gauge on their own in 1884, it pushed things past the tipping point. The competitive benefit was greater than the conversion cost. A modern example is GTFS, the general transit feed specification, which defines a common data format for public transportation schedules. This de facto standard

That's why when you head to a new city, it's not hard to use an app on your phone to figure out how transit works there. This started out from the passions of Tim and Bibiana McHugh, married transit technology managers at TriMet, the transit agency for Portland, Oregon. They had a deep frustration with how hard it could be to figure out a transit in a new city, compared to getting driving instructions at this at the time. That displeasure returned into action in 2005 when they got in touch with Chris Harrelson, an engineer at Google.

In July of that year, they would meet, and that conversation went so well that the McCuse had an export ready for it for it that same night. In December, that export would eventually lead to Portland becoming the first city features featured in Google's trans transit trip planner, less than five months after their first conference call to get things started. September of 2006 would bring five more US cities onto the platform. When the format was publicly released, it was originally called the Google Transit Feed specification.

But in 2010 it was renamed to the General Transit Feed specification to reflect the format's wider use and to keep the Google brand from causing some to shy away from it. Today, over 10,000 agencies in over a hundred countries use this standard. Before this all happened, there was no standard to work with. Transit authorities had to provide different data, consumers with different formats. You can imagine being in their shoes that a standard would make that task a lot easier. One format for anyone who asks

for it.

Makes it a lot easier to automate and get rid of toil. Just like the gauge change, its start wasn't federally mandated. The incentives naturally pushed adoption. Put yourself in the seat of a transit authority. If suddenly you had the option to have your schedules on folks' phones all over the country, and all you had to do was conform to a CSV file format, well that's an easy choice, right? Imagine the alternative building your own transit app or maintaining a competing standard of your own.

Those are all likely far more expensive and far more risky. In this case, we've got a situation where an option appears that enables a bandwagon, allowing a collection of players to switch their strategy towards cooperation, which is a standard in this case. The emergence of an easy to implement CSV standard empowered enough transit authorities to move together and create a tipping point, a threshold at which the network effects strongly push others to switch as well.

The other examples we've talked about involve the situation this seeks to escape, a trap where excess inertia keeps players frozen in a suboptimal strategy. In our historical example, we saw a bandwagon of lines come together to overcome it. In our modern example, we saw a handful of clever, passionate folks create something that enabled transit authorities to do the same.

As you reflect on your own work or your interactions with the services around you, what do you think is the GTFS example in your world? What neck n what network effects do or would enable it to work?

We've talked about hoisting machines, those things you've engineered to work around, keeping the lights on, while the core causes remain. The machines move the cargo, and the people keep moving, but it's frustrating, tedious, and not lacking for toil. We've considered the economics of the gauge switch and where malicious compliance can emerge. At times, it's profitable to let the friction ride to a point where people may actively push to keep it around.

We've considered how the incentives can we create can reinforce both desirable and not so desirable behaviors. At times those forces can push us into paralysis, but with awareness, it's possible to break the conditions and become free. We found a moment where these forces were overcome. That GTFS moment. A fresh option appears, a bandwagon forms, and the network net and the network effects help make the work happen. In your domain, your city, your state,

Your organization, your project, where are you right now? Are you mostly dealing with hoisting machines? If so, that's okay. The lights do need to be kept on, the thing needs to function, and people need to be able to access services. But do you know what your hoisting machines are? A good place to start, like in many situations, is to is to acknowledge it and take an inventory. These can find a home in your risk management practice as things to be managed, things to be mitigated.

Perhaps that means a home on your risk register. If you don't have one of those, that's another tool to look into. It's likely you won't be able to deal with all these things all at once. Often the problems that lead to workarounds are deep in the core of how a group of people work together. It takes time, compassion, research, understanding, and persistence to tackle the roots. Are you stuck with folks profiting off your friction? Perhaps the first move is to name them.

Who are these individuals or organizations? Why do they have a position that enables that behavior? What alternatives exist, if any? If there are none, is that in itself an opportunity? This again becomes your input for your risk management practice. You may find that these situations are less about technical excellence and more about the politics of who uses the thing and who gets paid. Attempting to solve these sorts of problems does not come without its own risk. A player with this kind of market position.

May have a lot of heft. Creating awareness, analyzing the impact, documenting risks, and considering solution paths, these activities may be the start of being able to do something about it. Perhaps you're waiting for that new option to appear and make your GTFS moment happen. What does that look like for you? Often these neat, innovative things aren't the most sophisticated. They're boring and elegantly simple. GTFS is a definition for building a CSV.

But because it's just that, it's useful and accessible. If you can identify the problems that need those solutions, you've done a significant part of the legwork. I'd ask myself, who are the people or organizations in your domain that can help you get the rest of the way? How can we make it so that the benefit is greater than the risk of cooperating? As you answer those questions, you can start to identify the concrete stuff in there. A use case for that would gain

Real value for real people, a return on investment that can be talked about in a budget meeting, a partner or larger network to connect and effectively spread network effects with. As you think about strategy, I'd be remiss not to mention that there's a pattern across these stories. Standardization tends to stick for two key reasons. A network effect makes a change reinforcing, like with GTFS and the 1886 gauge change, or an enforcing authority steps in to make it costly to do otherwise.

The Internet had its own version of a gauge change on january first, nineteen eighty three. ARPANET, Internet's predecessor, switched every host from TC an old protocol to TCPIP all at once. The DOD just set a deadline, and any machine that didn't switch lost access. When you contrast that with the Kirazac story we covered earlier, which had many claims but little in the way of penalties, you can see we're having teeth matters for this sort of thing. Just one more consideration.

As you think through what makes sense for your situation. Do you have a network to connect with? An enforcement lever to pull? Perhaps neither. But even that is okay. Once you know where you are, you can start to figure out where you want to go. Perhaps you can be the McHughs of your domain, turning a pain you feel into change for the community.

Let's take one last trip back to eighteen eighty six. You can now ride a train across whole regions of the country without worrying about the gauge of the rails. A train that once would have stopped in a place like Erie, hoisted, unloaded, perhaps stranded overnight, keeps on going. There's no need for those hoisting machines. And no one selling peanuts to stranded passengers because they aren't stuck there anymore. There was no decree from Washington. The cost of standing still became more apparent than the

as it went. In the South, a few hundred people in a hotel agreed to change their whole region's gauge. And so the work of thousands came together. And in a couple of days it happened. They made this choice to compete. They did it to remain relevant. They did it because the pain of standing still was finally greater than the cost of changing. That is a key thing to keep from these anecdotes. Better engineering or superior standards alone don't get us there. Attention on the friction

Making the harms legible. The network effect that follows can do a lot of the lift. Somewhere out there, someone's web scraper just broke on a state portal redesign. Someone's data transformation pipeline tripped on an upstream change. An API returned to two hundred, but nothing useful came back. Another Mchugh is about to emerge, spotting a problem that bothers them, and stretching themselves out to fill that gap. The trains keep on going.

You step into a new city, and the Metro schedule is right there on your phone. Perhaps it's your turn to see the next change through.