For those TDWTFians that aren't already aware, I work for a railroad, dealing with various tools used to munge various bits and bobs of data into the screens that will be used by our train dispatchers (US term -- UK dwellers call 'em signalmen, but it's really the exact same job) when the overall system I'm dealing with goes to production.
One of the things that train dispatchers must do in the course of their job is issue what are called "bulletins" to train crews warning them of track conditions up ahead:
- Patches of damaged track, etc. that must be traversed at a reduced speed in order to cross them safely
- Workmen operating on or near the track (the train crew must radio the work gang and ask their foreman for permission to cross the work site)
- Any other condition that impacts safety (footing issues, faulty grade crossings, outsized loads whether on the rails or crossing the tracks via road, ...)
Railroad operating rules specify that when a a bulletin is put out, it is put out by specifying the name of the track it applies to, and the start and end mileposts of the section that's damaged or being worked on, rather like a 411 report that says that Highway 19 is one lane between mileposts 30 and 40 due to resurfacing work. Also, just like how a street or highway name can change at an intersection, the name of a track can change at a switch -- more precisely, at the point of switch of the switch, where the paths actually diverge.
Unfortunately, though, the system I work on was originally written to apply track names to track objects, which can only have one name. This is a problem because of what I just said above -- the track name can and will change at a switch; furthermore, you use a different name to refer to an OS track when the switch is reverse (usually the bent path), as opposed to the default name for that (on-station or OS) track, which corresponds to the normal (usually straight) path.
This led to a bug-fight (over a single issue, mind you -- that issue number has become immortalized among significant portions of the team as a result) that lasted over a year and costed untold amounts of money, where they insisted that issuing a bulletin up to the point of switch of a switch or even figuring out which parts of the track received which names was utterly impossible, while a couple of my coworkers worked out case after case in mind-numbing detail, taking the most insane track layouts they could find on the railroad and going through every single possible path through them to assign which parts received which track name, depending on which switches were in what position.
Eventually, my coworkers devised a rather nasty algorithm that handles most of the simple cases, assigning track names to various parts of the paths and tracks that make up the railroad's junctions automatically based on the names of the tracks surrounding the junction; complicated parts of the railroad are still hand-finessed into shape, though, as they are rare enough that it was considered not worthwhile to automate them.
Unfortunately, the importer that brings in the mileposts where switches are located at was not updated to match this change, despite years having passed since the original fix was implemented. Worse yet, the incoming data feed it imports from relies on these track names in order to match switch milepost records up to the corresponding tracks the switch is connected to, and the algorithm that handles putting names on these OS tracks requires the milepost locations of switches in order to function correctly, leading to a catch-22 that forced the milepost location of every dispatcher-controllable switch on the railroad (over eight thousand of 'em total) to be hand-entered into the system while we tried to work out how to fix the import routine.
Finally, a partial fix was determined -- the switch milepost would be imported if the switch only attaches to one OS track, or if the names on each side of the OS track were the same; if the OS track's neighboring tracks were unnamed or named differently, then hand-entry would be the only option. While this got us most of the way there, the underlying bug proved to be impossible to fix fully -- the hand-entry would have to at least partially remain for the forseeable future, and the data source for this information couldn't come up with any additional tidbits they could extract in order to match up switches and their OSes, not without hand-entering those tidbits for every switch on the railroad.
Have any of you ran into catch-22 bugs, those that seem to admit only an incomplete solution, or no solution at all?