Sydney Train Describer System

The SydneyTrainDescriberSystem is one of the all time great software development disasters.

I wasn't there, but I've talked to enough surviors to wish I had time to write a book about it.

It was years overdue, millions of dollars over budget and never delivered. Meanwhile, millions of dollars of control room stood ready, empty and waiting.

Anything that could be done wrong was done wrong. I believe, and please correct any errors and omissions, that:

The developers wanted to use C++ but management insisted on C. So the developers wrote a bunch of macros to make C look like C++.

Code was written on one machine, stored on a different machine and cross-compiled on a third machine. That build took hours, and often ended in failure because the host was in a small unventilated room that would overheat. The most reliable way to get the build to work was to have someone hold the door open and fan the machine. (This may be a vile rumor, but I've talked to a person who claimed to do it.)

The code phase was planned to be 1 year, to be followed by a 3 week integration phase. (Because everything was so OO that integration would be easy). It went for 2 years with the original plans being updated.

Am I right in thinking that the misassumption was made that individual trains could be identified? (They can't. The only input is that a particular track section has a train in it, or not. It is necessary to know which train that is, and keep track as it moves from section to section.)

Network bandwidth was underspecified. When it became obvious that packets were being lost a 'fix' was implemented in which programs would exit and restart, thus greatly increasing the load on the system, to the point that other programs would also lose packets, exit and restart. Can you spell network-storm?

What else? Chronic staff turn-over. Several changes of lead-subcontractor. Adding extra developers to a late project. What else?

CategoryStory