Train Dispatch

The Sydney TrainDispatch system is one of those horrible failures that deserves a special place in software engineering history as a bad example. I didn't have the pleasure of working on it, but I know a few people who did. I'll add the things done wrong that I can think of and let others expand if they will. (It probably deserves a book to do it full justice.)

So what happened? Was it merely a figurative TrainWreck project (in other words, late and over budget), or did it cause a real TrainWreck to occur?

Possibly the single biggest mistake was that a lot of developers wanted to use C++ (possibly as an exercise in ResumeOrientedDevelopment?) but management felt C++ was too new and risky, so C was mandated. So the developers wrote a lot of macros to make C look like C++.

If the network overloaded a lot of processes would die and restart - causing an increase in network load.

Working conditions were poor.

Hardware was inadequate.

There was high turn over of staff and a number of changes of vendor.

Perhaps the biggest killer was a refusal to understand that the customer required things to FailSafe rather than FailOpen?. Very important with trains running around and all that.

From GoodAtLookingAround:

JeffMcKenna tells a great story about consulting with the SydneyAustralia? train dispatchers. There are many great aspects of the story, like they'd spent 18 months on ObjectAnalysis? and hadn't found a 'Train' object. The apropos part of the story is that the control room was located above the switching yards, with lots of fancy displays. When everything was going to hell, though, the dispatcher just opened the window and stuck his head out to see what was going on.