In case you're interested:
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.
"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.
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.
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.
What I'm saying is that the OP should take note of some of the people who dig what he's doing here and let them know next time he has a post on HN.
I like voting for good stuff and helping to promote interesting links on HN. When people who's stuff I like post new stories, they let me know, and I'm glad for 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.
"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?
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.
I really enjoyed your three grey beard stories and I'd love to read more if you have them.
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.
Just keep in mind that engineers in other industries do not have many of the same freedoms we do. They don't get patches, do-overs, and "oops our bad" opportunities.
So having modular, cleanly separated subsystems would matter as much for hardware as for software.
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.
It's the unknown and unanticipated failure modes that cause the worst problems. Predicted failure modes at least have code to deal with them, even if it's buggy. Unit tests reduce the bugs, but non-existant code for unanticipated failures, while it doesn't have bugs, doesn't solve the problem.
Thinking about correctly testing software is generally one of the best ways to improve your understanding of the problem.
I quite often find bugs during unit testing simply because I'm forced to think about how the software will break, rather than thinking about how it will (or should) work.
I think of it as being quite similar to waiting overnight to proof-read your own paper. You need to be in the context of the reader, not the writer, or your brain will skim over most mistakes.
No amount of testing the former will lead you to realize the latter. Sure, you might happen to come to the realization while writing the test, but you might do so over breakfast too.
I'm not saying "don't do testing". I'm trying to point out that it has limits. The fact that you've written tests and they pass doesn't get you off the hook for design bugs.
This is what FMEA (Failure Modes Effects Analysis) does: you assume failures of every part of the system, rank their likelihood and the end effect and see how your design handles it. A good FMEA assumes everything will fail and analyzes the impact. Unfortunately, comprehensive FMEA is expensive and time consuming so it's usually only done for critical subsystems.
You're a bit more likely to do it during a time you've set aside to fully consider potential failure scenarios.
What you're talking about is something I'd call white box QA. Which is valuable, though it's essentially just an extension of design, and has the same limits.
My broad point still stands: you can't "process" your way out of this with extra testing. Some bugs are just inherent, and stem from the fact that we're human.
It seems like most negative arguments regarding "unit tests" start by defining them as a small subset of what can be usefully tested, and then arguing against the value of testing such an incomplete subset.
I don't see the point of drawing such an arbitrary line. I leverage "unit" tests to automatically test units of code as completely as possible (not just 'verify features'), and I expect the same of tests that others write.
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.