|
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.)
|
|
|
|
|
Oh, sure:
1) I wrote a system that monitored the conditions of a process that results in various bio-gums... some of which are used to make ice cream -- imagine the devastation if there were an ice cream shortage!
2) I worked on an automated toll road system -- imagine the road-rage-induced slaughter that could result from a misplaced decimal point!
3) I then worked on a phone-sex billing system -- I shudder to think of the mayhem that could have been.
4) Currently I'm in a much lower-stress position; merely shuffling data between taxi cab dispatch systems -- Oh! The phone calls when I send two (or... ummm... twenty-two  ) cabs to get one passenger! 
|
|
|
|
|
I kid you not.
Still the damn thing worked. If it ever stopped working (actually the interface itself never did) there was a reset button on the desk that would reboot the offending subsystem and have the whole thing up and running again in less than 90 seconds - obviously that bit wasn't mission critical.
However the main system did have one spectacular test always done in the commissioning of any new upgrade - the "boot the plug for the entire rack out of the UPS" test. The whole system literally had its plug kicked out of the socket and was then replugged. Everything had to be back up and running in 30 seconds for the primary system and less than 2 minutes for the secondary systems without any data losses.
I just love Koalas - they go great with Bacon.
|
|
|
|
|
Especially in assembler, you never know what numbers you are looking at!
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))
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
