|
Actually it was coffee, but you've got the right idea.
Software Zen: delete this;
|
|
|
|
|
A few years back I was talking to a German nerdy type progrmmer, whose software was responsible for killing a whole bunch of children a year prior. I asked him how he felt about that, and he said it was good to get some feedback about how well the software was working, as up to the point in time of the incident he had heard nothing.
|
|
|
|
|
John Stewien wrote: it was good to get some feedback
Please tell us he wasn't that blase' about what he'd done  .
Software Zen: delete this;
|
|
|
|
|
He didn't exactly have a strong personality, so I've tried to convey the strange feeling that I got when he answered. Some people are too caught up in the mathematics to worry about anything else in life. I don't think the humanity side of it registered with him.
|
|
|
|
|
Why should it? It's not like he did it on purpose.
|
|
|
|
|
If you write software whose failure can cause injury or death, then you have a moral and ethical obligation to ensure its correctness.
The OP is pointing out that the programmer in this case is oblivious to the human cost of his ineptitude.
Earl Truss wrote: It's not like he did it on purpose.
I believe it's called "due diligence". If you choose not to exercise it, it's your fault.
Software Zen: delete this;
|
|
|
|
|
There was no mention of the programmer being inept in any way. I assumed that if he was working on software that might endanger property or people that it was tested "properly". We can't guarantee it's perfect, just that it has been tested as required. I agree that "due diligence" is the test. If you do it and it fails, it's probably not your fault even if you think it might be ...
|
|
|
|
|
Earl Truss wrote: even if you think it might be ...
Which is pretty much what most people would feel. Except for this programmer in question. No guilt and calling deaths "feedback" is inhuman.
|
|
|
|
|
My argument is that the programmer's attitude makes him incapable of exercising due diligence, and therefore the software was not tested properly.
Frankly, his response to the tragedy sounds sociopathic.
Software Zen: delete this;
|
|
|
|
|
Manager: Some people just died using your software. You'd better fix it.
Dev: Did you log it in Bugzilla?
Manager: No...
Dev: Then I'm not going to fix it.
or
Manager: Some people just died using your software. You'd better fix it.
Dev: Yes. They didn't use the right combination of arguments.
Manager: They died.
Dev: Not my fault they didn't RTFM. Dumbarses. We done here?
I'm making light of it but holy crap, what a whack job.
|
|
|
|
|
Man, you guys are reading a lot into a short comment from someone else. You really don't know the situation or the real conversation so it seems like some of these comments are assuming the worst. I'd think the people who responsed "not sure" deserve a bit more questioning.
|
|
|
|
|
Yeah. That's what we do. More interesting than being objective, fair and rational...
|
|
|
|
|
Given my experience with lusers- chances are, #2- Gigo and Pebcak are the #1 and #2 causes of "bugs" in any given system.
|
|
|
|
|
Isn't there a similar issue with people who design/build cars that people get killed in? Or safety systems, like airbags, that can inadvertently kill people under the wrong circumstances? Using "stuff" has an inherent risk, I guess.
There's side effects, too. I worked on a system that fueled a car on natural gas or propane. If installed incorrectly, by some third-party guy who took a course from us to be certified, there were some potential hazards. One of which was a backfire igniting a fuel injector and burning up an engine. Hard for the software to detect what was going on there, but the whole project had a certain safety aspect associated with it that we used to worry about.
But there are some things out of your control, once the product leaves your hands. I'm not agreeing with the attitude conveyed in the short quote. Maybe it was more of a coping mechanism on the guy's part, the way that air traffic controllers refer to "packages" rather than "airship with 300 lives aboard". I'd like to hear the whole story before passing judgment...
|
|
|
|
|
GuyWithDogs wrote: Maybe it was more of a coping mechanism on the guy's part, the way that air traffic controllers refer to "packages" rather than "airship with 300 lives aboard". I'd like to hear the whole story before passing judgment...
Yes, that was my thought also ... although I did not state it first. Thanks.
|
|
|
|
|
Yeah, that's why you hear military guys talk about "targets". Your mission is to hit the target, that way you don't think about the consequences, that hits you later...
|
|
|
|
|
Any indication of whether they had any QA on the team or did he have unit tests written?
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
I would assume that anything safety critical would go through a comprehensive battery of tests. Of course sometimes a real world environment can throw some surprises, especially with people who like to test what happens when you mess with things.
|
|
|
|
|
Please explain how you can be "not sure" if your software is destined for a life critical system.
I am mystified.
P.
|
|
|
|
|
maybe you wrote a part of a software packet, never knowing what it was for 
like the kid did in Die Hard 4.0 
|
|
|
|
|
A library that may or may not be used by life-critical systems.
|
|
|
|
|
Ah like the software for a TV Remote
xacc.ide - now with TabsToSpaces support IronScheme - 1.0 alpha 4a out now (29 May 2008) ((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))
|
|
|
|
|
Also a bit confused about the "no" ansers. Missing just "no" option 
"life-critical-system" and "not sure" should not be used together... (in my opinion)
Ok, the option "you wrote a libarary and this library may used without knowing it in a life-critical-system" may occur but should not occur... even such a third party stuff should be tested and tested and tested again if using it in a life-critical-system...
|
|
|
|
|
If you are a developer of libraries that are then incorporated into applications then you may not know the downstream uses for those applications.
Back in the '80s I was part of the team that wrote the Graphics Development Toolkit that IBM distributed and used on the IBM PC with PC-DOS and then OS/2. Most (if not all) of us had no clue what applications developers were using it and for what purposes.
However, and this is the caveat, in that case you should develop as though it could be used in such a critical situation!
|
|
|
|
|
I'm still not convinced.
Most EULAs these days explicitly say the software is not to be used in safety-critical situation, eg nuclear power stations and the like.
Similarly, why would you go through the process unless you absolutely had to? There are many aspects of developing for safety critical systems, but speed isn't one of them. (At least in my experience.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
