Tag Archives: Railcorp

Railcorp, you have a problem

Well, duh.

I think everyone knows you have a problem. Possibly even yourselves. Trains continually run late or are cancelled. The network clogs up causing follow-on delays. Even after degrading performance with a lower-throughput timetable you struggle to meet performance objectives (weak ones, too: eleven out of twelve trains arriving within 5 minutes of schedule). Even this reported performance is artificially high since large segments of the infrastructure are out of service every weekend and not counted. Trackwork is such a likely event that it’s the third most prominent link on the CityRail website, trailing only Home and Timetables.

But these aren’t the problem. These are merely symptoms of your problem. Your problem is best illustrated by your careers page. Or what’s not on your careers page. Apparently you have no need for anyone to work on scheduling, programming and optimisation of the CityRail network. This is clearly a ridiculously hard problem but it seems you don’t want anyone to help you solve it. I can see a couple of possible reasons for this, but they all mean you’re doing something wrong.

Perhaps you think the problem is solved, that what you have is good enough and the problems lie elsewhere. Um, no. I really hope you’re not that blind. You have scheduling problems.

Possibly you already have people employed in these roles. They’ve probably been at CityRail for a long time having moved up from being a station master or locomotive engineer or something equally irrelevant but are deeply familiar with the network etc. etc. Well, it appears that they suck, or have been promoted outside their competence, or just don’t care any more.

Maybe you bought some software from a better rail corporation elsewhere in the world, and you plugged in your network and requirements and out popped the current plan. Wait, so you’re telling me that no-one at RailCorp actually knows how the schedule is created? Please, please let this not be the case. You need to have this knowledge yourselves.

More likely you outsourced the planning and scheduling to some other company. If it was a big consulting firm, we are doomed. But in any case, you probably outsourced it to a team with no idea about rail networks, particularly the myriad complexities of Sydney’s. I’m sure you provided very detailed requirements and they might even have given you exactly what you asked for, but it still sucks. They don’t understand rail. It’s hard! And now whenever you want something changed you need to go back and write a detailed specification and open up the taxpayers’ chequebook and you already forked out millions up front and you’re running a tight budget so really it’s easier just to let it keep sucking.

RailCorp, you need to solve this problem yourselves, and you need to do it with the right people. You need to solve this problem yourselves, build an in-house rail planning and scheduling system, because the problem is really hard and depends crucially on details of Sydney’s particular infrastructure and requirements. You can’t just buy software from someone else. It will have been built with an entirely different set of assumptions, and it won’t work. You can’t outsource it. You already have the complex, detailed domain knowledge from running (barely) the network. You can’t effectively transfer that to another organisation. And the situation will change continually and you need to be able to react, fast.

You need to keep the knowledge of how the network is programmed, and how to create that program, internal. It needs to reside in the collective mind of your employees. The people with the responsibility for an efficient train network need to also have the knowledge and authority required to make it efficient. You can’t pass the buck — it’ll just end up on the floor and you’ll be bending down to pick it up when something … unfortunate happens.

But I have some good news. The people you need exist. In Sydney (and everywhere else). You need people who enjoy solving problems like this. People who get more enthusiastic the harder the problem is, the more complexities and special cases there are to be encompassed by an elusive elegant solution. People who will think about the problem constantly, never resting until they reach a perfect solution (which they never will), but who will reach a really really good solution with imperfections you won’t even notice.

These people are commonly known as computer programmers. Programmers have wet dreams about problems like this. They are hard-problem otaku. There is nothing to match the challenge of a problem like this, the complexities, the endless possibilities. Along with routing road traffic, programming a rail network is one of those problems that many programmers secretly long to attack but don’t have the physical network to try it out on. Good programmers dig a problem like this, and will work tirelessly to create an efficient, elegant and practical solution to it for the sheer joy.

Not just any programmers, of course. Many programmers suck. They’re probably the ones employed by the consulting firms you outsource to. That’s right, you pay a premium to use the crappy programmers who went to work at PWC or IBM because they couldn’t get a better job. You have a better job, potentially, and you need the best programmers to work on it. Perhaps the top 3% of computer science grads would be suitable. Maybe even the top 1%. But they would nail this problem.

You’ll have to do things a little differently though. For a start you need to employ only the very best, which seems counter to the way most government-related organisations work. It might take a while to find them, but you can’t just hire people who are capable, you need people who are brilliant. Luckily for you, they would go crazy for a chance to solve your problems. You’ll need to pay them too. What they’re worth, which is a lot. There are other jobs with challenging problems too, so you need to pay them commensurately or you won’t be taken seriously.

You won’t need many of them though. A team of five, with a great leader and great equipment, should set you back less than $1m a year. Give them what they want (responsibility, authority, freedom, time) and they will solve your problem. Not only solve it, they’ll give you the tools to solve it repeatedly and better. And the knowledge of how to solve it — why the solution works, on what assumptions it rests, its robustness and sensitivities — will be within RailCorp. The experts will be right there with you, and they will take responsibility for what they create.


I’m not particularly optimistic that you’ll ever do something like this. It’s too different to how you’ve worked for the past couple of decades. It might actually work. It probably requires some massive change at the top for you to grow the balls required to do this. No doubt the incumbent management would see all sorts of problems with a plan like this, and it’s not like I personally have deep rail experience. The NSW RTA have the right idea though. Their locally-developed SCATS traffic control system is effective and has been sold to some 80 cities worldwide (brochure). Take a leaf from their book.

In any case, this idea has one definite thing going for it – you’re not doing it now, and what you’re doing now sucks.