|
A "bug" is a bug; and if the bug triggered the failure, the software is at fault. A "bug" implies something that could have been prevented and is an error / flaw.
If there is no "bug" (in all its omissions and commissions), the software cannot be held at fault.
(The software is also not at fault if it says "Use at own risk"  , maybe. )
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
No, this is a chain of failures, leading to an undesired result. None of those in the chain can be totally absolved.
- The user followed instructions that should have been obvious (to the user) were wrong
- The documentation writer wrote these instructions
- The software developer wrote code that had a bug in it
- The hardware developer built hardware that failed when the wrong instructions were passed to it
- The QA / integration testers / whatever failed to catch any or all of the above
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
As an embedded dev of 24 years or so, who worked on detonation systems, financial systems and medical research systems, I disagree.
Quote:
The user followed instructions that should have been obvious (to the user) were wrong
So? If you buy a TV and wire it up wrong do you expect the house to burn down? No, because of things like breakers in the mains circuit, one-time fuses in the TV, diodes in the power supply, earthing in the enclosure (for a metal TV). A device which results in an expensive incident when used incorrectly is not fit for the market, and the manufacturer will sooner or later be sued.
There are limits, of course. If you buy a TV, pour petrol all over it and turn it on, you can't expect to win a lawsuit when the house eventually burns down.
Quote:
The documentation writer wrote these instructions
Documentation authors only write what is specified. If they put an instruction of the form "Do action $FOO", they didn't make that up - someone, somewhere informed them that that action is supported by the device. Of all the people in this scenario, documentation authors are the least culpable, because they don't get to decide what the product can do, they are only told what the product can do.
Quote:
The software developer wrote code that had a bug in it
Definitely the software developers. After all, the bug is the thing that was created by the developers in the first place. It is unreasonable to expect that a bug will never be triggered.
Quote:
The hardware developer built hardware that failed when the wrong instructions were passed to it
Not so culpable. Hardware is built to within a certain spec with specified tolerances, and since the bug put the hardware out of spec all bets are off. It's up to the product designers (including the software devteam) to ensure that they choose products with failure modes they are comfortable. If a product had a rotor that will destroy everything if rotated backwards, it's up to the team to choose a motor driver that cannot change rotational direction. If they choose a driver that allows rotating in both directions, then that's their fault when the bug causes the rotor to reverse direction.
Quote:
The QA / integration testers / whatever failed to catch any or all of the above
Testing cannot assure the absence of bugs, testing only detects the presence of bugs. The test for the action $FOO must have passed in the test jig, after all, because every single thing that the devteam says the product can do is tested.
Ultimately, it's only the software dev team that is responsible because it originates with them and them alone. After all, they produced the product and said "Performing action $FOO is safe".
Testers tested the action $FOO, it passed.
Documentation writers were told by devteam to put $FOO into the documentation, they were told by the QA team that $FOO was tested, so they put that into the docs. Did you expect the documentation authors to test it too?
User read the documentation, then tried to do $FOO. Why do you think it's their fault too?
The hardware vendor sold hardware that did exactly what it said it will do. You can't blame them if the bug sent what the hardware considers to be a valid command. I'm sure the vendor, or a competing vendor, would have sold a product with a reduced set of valid inputs. The devteam should have chosen *that* product.
|
|
|
|
|
All are at fault! First, who wrote the documentation? Was the documentation meant for using the hardware or the software? The user was using the hardware and not necessarily the software, so it would appear that the documentation was for the hardware and not for the software. This causes the person(s) who wrote the documentation to be at fault. Was it the hardware manufacturer who wrote the documentation? Who was the documentation "obviously incorrect" to? If it was obvious to the user, then the user is clearly at fault for following the documentation and not questioning if it was right. The hardware may or may not have been defective, and the software caused it to operate in a way it wasn't planned for. This of course can be viewed as bad design work as the hardware manufacturer should have anticipated that behavior in its design. The bug in the software can only be viewed as the fault of the programmer and those who tested the software. The programmer should have anticipated all possible scenarios and the testers should have tested all possible scenarios. Clearly, they missed something though. Thus, there seems to be plenty of fault and blame to go around.
I see some visits to lawyers in the near future, and probably multiple lawsuits ultimately being filed. Who will be the big winners here? The lawyers of course. The documentation will get fixed, the software bug will get corrected and the hardware will be improved upon. Hopefully the user will become wiser as well, probably to the point of not even reading the documentation next time. This then brings us back to the question of 2 weeks ago, "Do you expect users to read the instructions when using your apps?". In this case, at least the user read, and even followed, the instructions. Unfortunately, the whole thing turned out to be a major SNAFU, and the lawyers will make lots of money from it.
|
|
|
|
|
"Fault" is such a loaded term and is highly subjective in most usages, including this one. If we want to know where the improvement opportunities lie, then the poll did not provide enough information and the relevant questions are:
Did someone detect the defect in their testing/QA but decide to release with the defect? What was their reasoning and was it in the release notes?
For those who did not detect the defect, did they follow testing/QA protocols which are reasonable for their industry and use-case? If not, would following protocol likely have detected the defect?
|
|
|
|
|
Ownership is needed for sure. The issue at hand is how can we fix this so that it, or something similar, doesn't happen again, and that is solved by the decision-maker at the top - the owner.
|
|
|
|
|
I checked "The Developer" since it should be very very difficult to cause big elephant-ups by mere clumsiness in any software. Like: "if you double click the red icon during the process the server park will be taken offline".
So it is bad programming but ...
in any decent development organisation such matters are up to the product owner or some other organisational function...
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I can't tell if the question writer has an axe to grind or what, but who cares who's at fault? Who can fix it the quickest, safest way?
|
|
|
|
|
The question got me thinking, so perhaps that point was to increase our collective ability to think things through. Something which the user is not do in this hypothetical situation in that they took an obviously incorrect action.
|
|
|
|
|
If we push the responsibility onto the documentation writer, we can - as software developers - make sure that none of us will be blamed. We never do any sort of documentation writing!
|
|
|
|
|
Yeah, I do all of my own documentation. I know the code best, so it makes sense.
|
|
|
|
|
Like, I am a car mechanic, knowing the car best, so I am the one who should teach you how to drive in heavy city traffic.
If you are talking about software maintenance documentation, you may be the best person to write that documentation - although I have seen some outright awful attempts by software guys to write even that sort.
For the end user documentation, you need a domain expert. If the domain is software development - say, you are making development tools for the FOSS community - then you may be domain expert, knowing in detail the problem(s) to be solved, well established work patterns and solutions, the professional terminology (domain specific), etc. etc. If you are a good writer, maybe you are the one. ("Good writer" covers both mastering the language, and the skill to organize the information in proper ways.) If you are writing software to be used in areas where you are not a domain expert, then leave user documentation to someone else.
|
|
|
|
|
It isn't always obvious that documentation is incorrect: it's written by people who should know what to do for people who don't.
What's "obviously incorrect" may be clear when your GPS tries to send you via a river rather than a road, but in software it's never that cut and dried.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Totally agree.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Since the hypothetical situation states that the documentation was obviously (in this context obvious to the user) incorrect, then the user was invoking the documentation as authority rather than taking responsibility for their action. There is plenty of fault upstream of the user but it doesn't relinquish the user of using good judgement.
|
|
|
|
|
I love this example because it allows to portray how even then the user cannot possibly be held accountable because there is no certainty the obvious will be noticed, because:
- Even when it is obviously heading towards a river, the user may realize it too late (you still need to maintain focus on the driving rather than the GPS or the possibility it may be blatantly wrong).
- The user may be colorblind, you cannot assume that anything will be obvious to any user. The river may look the same as the road for certain users.
- The user may take for granted that the manual should be trusted and his suspicions are incorrect. It is the responsibility of the supplier to review and correct it. If it is so obvious to the user it would be even more to the supplier and failing to properly review it is at the suppliers fault.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
There's no such thing as "obvious" that covers every user. If the software/hardware/documentation allows something to happen, some user somewhere will make it happen.
|
|
|
|
|
In my view, partially correct. It's not the user (definitely) but it's not the docs either. The docs are never read so how can they be at fault?
cheers
Chris Maunder
|
|
|
|
|
The issue is in the whole process that lead to the event, not the failure of a single actor, the documentation writer made a mistake that went unchecked (possibly because the project wasn't properly explained to them), the software wasn't properly tested and the hardware wasn't resilient enough.
The only possibility in which the user could have been considered at fault would be if they didn't read the (incorrect) documentation 
Edit: it's nice to see that nobody blamed exclusively the sw dev
|
|
|
|
|
It's important to identify the source or sources of the problem in order take measures to reduce the likelihood of it happening again.
|
|
|
|
|
Absolutely, but identifying the source of problems has nothing to do with finding a singular scapegoat that is "at fault" which will reduce the probability that someone will flag their mistake early and instead hope nothing will happen.
And consider that scapegoating is especially harmful when we know many problems exist and are not caused by a single person
|
|
|
|
|
Sometimes it is necessary, specially on customer and provider relationship.
It needs to be done so for damage compensation purposes. In such a situation who's to blame is important on the broad scope, less important on the customer's and provider's own scopes. Then it is important to identify the flaws in the process that could've prevented the issue on either side.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Either multiple choice or better choices.
The only one that is NOT guilty (in my opinion) is the user. All the rest should be, at least partly, liable.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Yep.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Since the hypothetical situation states that the documentation was obviously (in this context obvious to the user) incorrect, then the user was invoking the documentation as authority rather than taking responsibility for their action. There is plenty of fault upstream of the user but it doesn't relinquish the user of using good judgement.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
