Tag Archives: complexity

Trains and complexity

When I went to Japan many years ago, I marveled at the complexity of the Tokyo JR system. There is separate pricing between every two stations, so when you get into the system you may need a different ticket amount to get out at any particular stop. At every station you see a map that looks something like this (fares listed in Yen):

At first glance, you get thrown by the complexity of it, and are really concerned you won’t do it right. What if you bought a 210 yen ticket, but need 290? It turns out, the system is built to handle that, because if you happen to have too small a ticket to exit the system, the automated gates will tell you to go to the fare adjust machine (available at any station), which will read in your ticket, tell you how much more you need, and give you a new ticket to get out of the system. All of this is done with no user interaction, it’s all machines and magstripes.

Once you realize this is the way it works, you change your strategy. Get the cheapest ticket that lets you into the system, and let the machine worry about the math when you want to get out. Simple as pie.

A couple years after I went to Japan I went to Germany for the first time, specifically Munich, and I got really confused about what tickets to buy to get around on their train system. In Munich there is no automated system for collecting tickets. There is rarely any checking tickets at all. As my friend Clemens once told me “But who would be on the wrong train with the wrong ticket?”. With no machine as the middle man the system can be as arbitrarily complex as the mind can come up, and doesn’t need to make any sense. There are tickets for 1 person for 1 day between certain zones. There are tickets for 1 person for 7 days between certain zones. There are bonus tickets for one trip beyond the zone your other ticket works for. There are tickets that support multiple people on one ticket. I met Clemens’ uncle because the most sensible ticket to go to the alps was for “up to 5 people”, and we only had 4 in our party.

The tickets just sit in your wallet and are never shown unless the random ticket inspector finds you. This never happened to me in Munich, but it did in Berlin years later. It is assumed you are in compliance, and it’s handle by exception if you aren’t. But it’s all handled by people interpreting German law. As complex as the Tokyo system is, the Munich system is so much more so, because there is no computer enforcement.

There are so many interesting ideas that come out of that juxtaposition, some pro for either side. Could you even make an automated system to handle the German law, or is there a realm of complexity beyond which automation is no longer feasible (lesson: some times doing it by hand is cheaper)? What would you need to change about the German system to make it validatable (lesson: some times you can’t test your software as it is written, and you need to change it to be a testable system)? Which is more efficient? In the German system there is no need for ticket checking machines, at the cost of much more time needing to be spent by people figuring out the right tickets they need at any given time (lesson: every system has a cost, if the implementer isn’t paying it, who is?). How much raw efficiency is gained by Trust being an explicit part of the equation?

Probably most importantly, both systems actually work, and have been for a long time. In the real world, there is never only one solution.