This will be the last of these stories for a while. The previous two stories pretty much sank without trace, so I thought I'd finish and submit this one, then stop writing them up and re-think the effort.
It sounds like one of these stories with educational/entertainment purposes rather than a description of an actual problem or event. I did find one reference -
"D. E. Stevenson attributes this story to Nancy Leveson, Software System Safety, STAR '93, Ontario at Darlington, Ontario. 1993.
A torpedo was designed to self-destruct if it turned 180 degrees. Unfortunately for the test ship the torpedo stuck in the tube and the captain turned the ship around for port "
It sounds mildly more plausible since it doesn't begin with the rather improbable torpedo design problem of 'submarines shooting themselves with their own torpedo'.
Still, if tasked with designing a reasonably safe torpedo, one of the very first things you're likely to come up with are 'armed' and 'safe' modes with the torpedo staying in 'safe' mode until it is about to be launched. The next obvious safety feature would be to make the torpedo return to 'safe' mode the moment significantly abnormal conditions are encountered - say, stuck in tube, wildly off-course, etc.
Adding a self destruct mechanism seems highly unsafe - there's the problem of the self-destruct mechanism malfunctioning and activating at an inopportune time. Additionally, if the torpedo has no idea where it is, the last thing you probably want is having it blow up - possibly near you or a friendly.
The actual stories of the difficulties developing WWII torpedoes are quite interesting and offer plenty of lessons in complex systems design, testing and deployment - see:
A design flaw that must have been particularly galling: "The conventional contact exploder was designed for the earlier, slower, 33 knot, Mk 13 torpedo. The newer, faster, 46 knot, Mk 14 torpedo had higher inertial impacts that would cause the firing pin to miss the exploder cap. " In other words, the more squarely you hit your target, the more likely the torpedo would fail.
It's a pity people don't seem to be reading these. As a young coder, I find tales of the earlier ages of computing and electronics fascinating, and they serve as a good reminder that even today there are areas of computing where the philosophy is completely different from the release early/release often nature of the web development sector I work in.
Your stories are most appreciated. If I extrapolate from myself, the problem is simply that the people who enjoy submissions like these are often reluctant to go through the new submissions.
This was a great story with all kinds of lessons about the things we do every day and understandable by almost anyone, including people new to our industry.
This will be the last of these stories for a while.
RiderOfGiraffes, I urge you to reconsider...
The previous two stories pretty much sank without trace
Which probably means nothing. There are many reasons stories do or do not get votes, with quality and interest only two of them. You must also consider time of day, day of week, competition from other stories, competition from other sites, competition from non-internet activities, competition from work, mix of people on-line at that time, mix of lurkers, mix of people who don't vote yet, etc., etc., etc.
Over the years I have made the exact same comment multiple times just to see if the reaction would vary, and it always did. One comment got over 60 up-votes and 6 months later got none.
What does this mean? Nothing. Just keep on posting.
...then stop writing them up and re-think the effort
It's perfectly normal to re-think the effort, but don't stop writing while you're rethinking.
This is a place for builders and entrepreneurs. We may eventually quit, but usually long after others would.
I have 2 signs over my desk, "It Doesn't Matter" and "Jabez Wolffe". When things get tough, the former keeps me from having a stroke and the latter keeps me from quitting. Jabez Wolffe attempted the English Channel 22 times without success. Once, when he didn't know where he was and conditions were dangerous, he quit 100 yards from shore.
Don't be Jabez Wolffe. Your next story may make a big difference in someone's life. If I'm on-line at the time, I'll vote it up. Keep 'em coming.
You need to round up a voting posse to help push your stories up onto the front page. Doesn't take much, just 1-2 HN users who like your stuff and will toss you a few votes when something goes up.
Edit: Of course they need to be people who really like your stuff. Not suggesting he game HN, just that he let fans know when there's a post they can check out.
It would be a very sad thing if that's what it took to get stories to the front page. Unfortunately it seems that quite a few people have adopted your 'tactic', I always find it a little suspicious when links have been posted literally minutes ago and already have 3-5 upvotes without any comments, especially if they then scroll off the new page without receiving further upvotes.
My guess is that those are simply sockpuppets used for the initial votes. The sad thing is that plenty of times the strategy seems to work.
Seems implausible to me. Rather than a self-destruct, it would be more plausible to just disable the explosive trigger altogether. If a torpedo fails to hit target for whatever reason (including, but not limited to the original problem) you don't necessarily want it to explode in some random place. Nor is it clear how, if this failure did occur with loss of all hands, we would ever have known about it.
Despite this, I take the point of the story to be that self-corrective failure detection mechanisms should not be capable of causing greater harm than the maximum plausible damage of the problem they were intended to correct.
Possibly because you don't want your adversary to get one of your unexploded torpedos and copy / reverse-engineer / exploit a design flaw. Tactically that'd be far more devastating than losing a ship or two.
Interesting (and depressing) story. On one of your posts you say:
"Sometimes because of the nature of my work I get to hear stories from a greybeard with a past that is, well, "interesting." And again, because of the nature of my work, or more accurately, because of the nature of their work, the stories can't be verified."
I'm in the commercial world producing kit (hardware and software) to assist with the analysis of real-time data used in quasi-governmental organisations. That means I work regularly with military and ex-military personnel, and they talk to me off the record.
You can probably track me down if you like, but I generally try not to make the connection between my on-line persona and real-life work obvious. Feel free to email me if you'd like to know more.
If the sub sank with loss of all hands--not unlikely if a torpedo went off in the tube--how did anyone know about this? A hell of a lot of submarines never came back to base in WW II, and in most cases a) there were no survivors, b) very little debris seen.
I also wonder about the basis of the story. The USS Tang was sunk by its own torpedo in October 1944. That leaves about 8 months for the changed torpedoes to operate.
I know it's a joke, but the truth is that this is exactly the kind of bug that unit tests won't find. The unit tests would have simulated a bunch of gyro settings, with and without a single gyro failure (but not two gyro failures, as that was an accepted design limitation).
Running the gyros with the torpedo still on the boat, however, would not have been tested because the designers didn't think of it. If they had thought of it, the failure wouldn't have happened in the first place.
Testing can verify that your software works within the space of behavior that you already know about. It can't make up for your failure to understand the problem fully.
Written as a joke, but in my line of work (embedded systems) this is a big problem. Because most of a product's operation may depend on external inputs, it can be impossible to write a suite of unit tests that are useful without also building and automating hardware to generate the external stimuli.
We've come up with some creative responses to this, but nothing remotely like what's possible when you're just moving data around and not, e.g., testing the hardware's ability to start a 300hp diesel engine at it's low-temperature limit.
[+] [-] RiderOfGiraffes|16 years ago|reply
In case you're interested:
http://news.ycombinator.com/item?id=996250
http://news.ycombinator.com/item?id=994358
[+] [-] pvg|16 years ago|reply
"D. E. Stevenson attributes this story to Nancy Leveson, Software System Safety, STAR '93, Ontario at Darlington, Ontario. 1993.
A torpedo was designed to self-destruct if it turned 180 degrees. Unfortunately for the test ship the torpedo stuck in the tube and the captain turned the ship around for port "
It sounds mildly more plausible since it doesn't begin with the rather improbable torpedo design problem of 'submarines shooting themselves with their own torpedo'.
Still, if tasked with designing a reasonably safe torpedo, one of the very first things you're likely to come up with are 'armed' and 'safe' modes with the torpedo staying in 'safe' mode until it is about to be launched. The next obvious safety feature would be to make the torpedo return to 'safe' mode the moment significantly abnormal conditions are encountered - say, stuck in tube, wildly off-course, etc.
Adding a self destruct mechanism seems highly unsafe - there's the problem of the self-destruct mechanism malfunctioning and activating at an inopportune time. Additionally, if the torpedo has no idea where it is, the last thing you probably want is having it blow up - possibly near you or a friendly.
The actual stories of the difficulties developing WWII torpedoes are quite interesting and offer plenty of lessons in complex systems design, testing and deployment - see:
http://www.ww2pacific.com/torpedo.html
A design flaw that must have been particularly galling: "The conventional contact exploder was designed for the earlier, slower, 33 knot, Mk 13 torpedo. The newer, faster, 46 knot, Mk 14 torpedo had higher inertial impacts that would cause the firing pin to miss the exploder cap. " In other words, the more squarely you hit your target, the more likely the torpedo would fail.
[+] [-] camtarn|16 years ago|reply
[+] [-] sfk|16 years ago|reply
[+] [-] shaunxcode|16 years ago|reply
[+] [-] samdk|16 years ago|reply
[+] [-] edw519|16 years ago|reply
This will be the last of these stories for a while.
RiderOfGiraffes, I urge you to reconsider...
The previous two stories pretty much sank without trace
Which probably means nothing. There are many reasons stories do or do not get votes, with quality and interest only two of them. You must also consider time of day, day of week, competition from other stories, competition from other sites, competition from non-internet activities, competition from work, mix of people on-line at that time, mix of lurkers, mix of people who don't vote yet, etc., etc., etc.
Over the years I have made the exact same comment multiple times just to see if the reaction would vary, and it always did. One comment got over 60 up-votes and 6 months later got none.
What does this mean? Nothing. Just keep on posting.
...then stop writing them up and re-think the effort
It's perfectly normal to re-think the effort, but don't stop writing while you're rethinking.
This is a place for builders and entrepreneurs. We may eventually quit, but usually long after others would.
I have 2 signs over my desk, "It Doesn't Matter" and "Jabez Wolffe". When things get tough, the former keeps me from having a stroke and the latter keeps me from quitting. Jabez Wolffe attempted the English Channel 22 times without success. Once, when he didn't know where he was and conditions were dangerous, he quit 100 yards from shore.
Don't be Jabez Wolffe. Your next story may make a big difference in someone's life. If I'm on-line at the time, I'll vote it up. Keep 'em coming.
[+] [-] rjurney|16 years ago|reply
[+] [-] brandnewlow|16 years ago|reply
Edit: Of course they need to be people who really like your stuff. Not suggesting he game HN, just that he let fans know when there's a post they can check out.
[+] [-] jacquesm|16 years ago|reply
My guess is that those are simply sockpuppets used for the initial votes. The sad thing is that plenty of times the strategy seems to work.
[+] [-] jrd|16 years ago|reply
Despite this, I take the point of the story to be that self-corrective failure detection mechanisms should not be capable of causing greater harm than the maximum plausible damage of the problem they were intended to correct.
[+] [-] woadwarrior01|16 years ago|reply
[+] [-] thechangelog|16 years ago|reply
"Sometimes because of the nature of my work I get to hear stories from a greybeard with a past that is, well, "interesting." And again, because of the nature of my work, or more accurately, because of the nature of their work, the stories can't be verified."
What's the nature of your work?
[+] [-] RiderOfGiraffes|16 years ago|reply
You can probably track me down if you like, but I generally try not to make the connection between my on-line persona and real-life work obvious. Feel free to email me if you'd like to know more.
[+] [-] ErrantX|16 years ago|reply
[+] [-] exoself|16 years ago|reply
[+] [-] balding_n_tired|16 years ago|reply
I also wonder about the basis of the story. The USS Tang was sunk by its own torpedo in October 1944. That leaves about 8 months for the changed torpedoes to operate.
[+] [-] cmkrnl|16 years ago|reply
[+] [-] kylemathews|16 years ago|reply
[+] [-] RiderOfGiraffes|16 years ago|reply
[+] [-] mvaerle|16 years ago|reply
[+] [-] ajross|16 years ago|reply
Running the gyros with the torpedo still on the boat, however, would not have been tested because the designers didn't think of it. If they had thought of it, the failure wouldn't have happened in the first place.
Testing can verify that your software works within the space of behavior that you already know about. It can't make up for your failure to understand the problem fully.
[+] [-] HeyLaughingBoy|16 years ago|reply
We've come up with some creative responses to this, but nothing remotely like what's possible when you're just moving data around and not, e.g., testing the hardware's ability to start a 300hp diesel engine at it's low-temperature limit.
[+] [-] joshu|16 years ago|reply
[+] [-] hello00768|16 years ago|reply
[deleted]