Gaming the System

 There's an old adage about being very careful about how you align a system to match its professed goals: if the goals are out of alignment, even though the intent may be clear, at least some actors will try to game the system.

(A classic example in software development is to measure productivity in lines of code, and make compensation dependent on productivity. At best, this provides no incentive for clean, concise code; frequently, it actively encourages coders to write deliberately verbose code to boost their lines of code.)

I have recently observed a specific example of this in another domain, namely, the TTC.

I regularly use a bus route which is relatively short and which is essentially a direct line from the station for most of the route, but splits into a loop at the end. I catch it on the leg going back to the station.

During rush hour, the predictions provided by the feed based on real-time data from the TTC are fairly accurate. Mid-day, they regularly would result in missing the bus.

The route is scheduled with busses N minutes apart, based on the number of busses on the route at the time; every 15, 20, 30 minutes (10 at rush hour).

To maintain the schedule, the drivers are supposed to get to the far point of the loop where there is a stop they can wait at and then come back at a scheduled time.

Because the apps available for TTC predictions track busses in near-real time, I can see what happens: busses wait at the wait point until they are three minutes early, and then leave. This means that what was a ten-minute prediction when I looked at it, and a six-minute prediction at the point they start to move, suddenly collapses by a significant amount.

What is going on? The problem lies with the TTC's metrics. They count a bus as being on time if it is within a three-minute window on either side. This is meant to allow for problems with heavy traffic or construction which drivers can do little about, or for random times when fewer people are waiting for stops than the statistical average, speeding up the bus by reducing the number of stops. It is not meant to encourage drivers to start moving as soon as they are technically "on time", but that is what systematically happens.

They start moving early because they will get to the station "on time", but really three minutes early, and then have a three-minute longer break. (The same drivers tend to arrive on one side of the station, let off their passengers, and then sit there until just before they have to leave, proceeding to their loading bay only at the last moment, even in very unpleasant weather. The TTC consistently conveys a sense of being run for the benefit of its employees rather than its customers.)

At rush hour there are no delays built into the schedule; the only divergences from longer-term live predictions will be as a result of heavy traffic, which is rare on this route.

This leaves users with no recourse. The drivers have committed no formal infraction. The TTC could analyze the collected route data and penalize this behaviour if a driver engages in it systematically, but I'm willing to bet that the likelihood of the Union to grieve such a change in the rules is a barrier to such a step.