|
"obviously incorrect documentation" in what way? Does the document contain a version number? Does it state it may contain unreliable information? Does it state may cause damage if used improperly? As long as it clearly contains wording to effect that the makers are not liable for damages caused by in-properer use of this product, the user is at fault. There is no court in the United States the will hold an entity responsible for damages caused by an improperly used product when such use is clearly stated in user documentation. For special use stuff there are usually a big RED stickers all over the packaging as well as keep away for children wording. But it is not uncommon, in these litigious times, for some idiot that would attempt to file suit against the maker toaster when said idiot threw the live toaster in a bathtub that causes their house to burn down. Neglecting to read the documentation is also no excuse either. Anyone indenting to sell a product, with at least one functioning brain cell, should at the very least know to consult someone who knows how protect themselves against product liability.
|
|
|
|
|
THIS.... exactly...
Amit Joshi
Value of the value is valued only if its value is valued.
|
|
|
|
|
Should include them too.
But, in the end, the captain is responsible for his ship and crew.
|
|
|
|
|
Perhaps because as mental defectives, they cannot be held responsible for anything.
Seriously, unless the initial requirements were for a device that was unsafe, impossible to build in the time allotted, or violates the laws of physics, I don't see how "Marketing" would be involved in the blame-fest. The other departments also have a responsibility to speak up when this is the case.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
that or the one with least competent management.
It is also funny how many are defending the user and could also be the ones claiming PEBCAK.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
"Users" can do all kinds of stupid things, which is why equipment has (or should have) safety features.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
This survey question reminds me of that Zen kōan
|
|
|
|
|
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
|
|
|
|
|