Re: software failure question

[Ted Dennison<dennison@telepath.com>]

>In article <4ZmA6.1693$Ak1.181271@newsread2.prod.itd.earthlink.net>, Phaedrus
>says...
>>
>>I'm reminded of another famous software failure, that may or
>>may not be an urban legend:
>>According to the story, when programming a helicopter simulation
>>for the Australian military, someone noticed that they didn't have
>>any kangaroos.  Rather than write a whole bunch of new code to
>>simulate them, they just derived a new subclass from the class that
>>they used to simulate the ground troops.

I forgot about this part. The OO mumbo-jumbo that got thrown in here was just
made up. They were interfacing their virtual sim to another simulation capable
of generating and controlling other entities (perhaps MODSAF). When this is
done, each entity MODSAF is controlling needs to be mapped on the virtual sim to
an entity that the virtual sim's image generator knows how to render. Its fairly
common in such a setup to map one entity to another similar one that MODSAF (or
whatever they are using) doesn't have. I've been on two different projects that
did this. There's nothing particularly OO about it. But the story has slowly
mutated itself into some kind of unspecified object lesson on the dangers of OO
programming. Go figure.

To put my previous post in perspective, they weren't expecting SAMs to come out
of MODSAF, so they didn't set up a mapping for them. That meant they got the
default mapping, which happened to be multicolored beach balls. :-)

BTW: I've personally seen a (simulated) marine helocopter fly in close formation
with a heap of rubble for over thirty minutes due to a similar issue. We had
them keep flying that long so we could monitor the network traffic and try to
figure out where the bug was. The pilots entertained themselves during this time
by pretending that the squarish rubble heap was a Borg ship. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com