|
There should be good error checking for unforeseen circumstances especially when there is a chance it can damage hardware. With all the hacking going on and bad actors looking for flaws, there is no excuse for software to have such an easy way to exploit it.
|
|
|
|
|
It's easy to finger point at the tech writer, but let's consider how many times documentation is out of date. That's a management decision, not the tech writer's.
Without "why?" answered, it's not possible to determine if the fault lies in design, manufacturing, testing/QA/QC, or software.
This survey reminds me of several managers I've worked under, whose sole interest during a problem investigation was determining who to blame. Figuring out the problem was really low in priority.
Sometimes the problem begins with management making bad or ill-informed decisions, which wasn't an option in the survey. 
|
|
|
|
|
Here are my thoughts - including estimated blame percentages (that will not add up to 100%, they are individual)
The user (~0%)
Blame:
Doing something obviously wrong (e.g. setting voltage to 42 instead of 24), especially if the
correct value is used elsewhere.
Should have questioned the supplier.
No blame:
Documentation should be seen as correct.
When unsure you follow the 'power structure' - that is the user documentation.
The documentation writer (~60%)
Blame:
Should have a proof-reader
Should test instruction are correct on the hardware/software being used.
No blame:
The documentation is for a range of hardware and is correct for a subset of hardware.
Incorrect information was provided as incontrovertible fact.
The software developer (~60%)
Blame:
There is a bug in the software.
Did not read hardware documentation correctly.
Software should be fault-tolerant.
No blame:
Software should not be able to damage hardware.
There could be a use case for using the software as described that does not cause a hardware failure.
Lack of hardware documentation could mean the bug was impossible to anticipate.
The hardware manufacturer (~50%)
Blame:
Hardware should be fault-tolerant.
Possible damage was not anticipated. This could be considered a hardware bug.
Safety gap was not documented.
No blame:
Not every scenario can be protected - document what can not.
There could be a use case for using the hardware as described that does not cause a hardware failure.
The hardware/software integration and system tester (~80%)
Blame:
Did not read/check documentation and test on hardware/software being shipped.
Did not check the software.
Did not check the hardware.
No blame:
Did not have the exact software/hardware/documentation that caused the hardware failure. (Who shipped different hardware/software?)
Hardware/software might have changed since shipping.
|
|
|
|
|
Users rely on supplied documentation, so they cannot be held responsible if it is incorrect. In fact users can rarely be held responsible for software or hardware failures.
|
|
|
|
|
Richard MacCutchan wrote: Users rely on supplied documentation
No, they don't. That was thirty years ago.
|
|
|
|
|
Well the question clearly states that they are following the documentation.
|
|
|
|
|
That is a such an exceptional case that I prefer not to take it into consideration. 
|
|
|
|
|
Richard MacCutchan wrote: Users rely on supplied documentation
... as door stops or monitor stands.
If printed anyway. Electronic documentation has zero value to users what so over.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
if the purpose of the question is to find someone for the blame game, I don't find the necessity to answer it
if the purpose is to find where we can improve, the question needs to be rephrased. And in that case, I would say all can be improved:
- documentation obviously needs to be corrected
- both hardware and software need adjustments to make it impossible/difficult to be misused. Never trust users and always assume things can go wrong
- maybe deployment pipelines (where automated tests happen) and testing process can be improved too (add more test cases to cover this)
|
|
|
|
|
So we are talking now about a bad outcome of the common mess of today's product development...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
"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?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
