|
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.
|
|
|
|
|
Doug Domeny wrote: in this context obvious to the user I didn't see it like this.
If the user knew it was wrong... then he has part of responsibility too.
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.
|
|
|
|
|
where the project manager in this list
company accepting fault and helping to resolve the issue, if in money or replacement
release statement that fault, and follow up other sales
programmer can add some fault tolerance next time
documentation and tester crossover that documentation followed for issues
work environment that allows for implementation errors to be raised, tracked, and resolved and retested.
|
|
|
|
|
Incorrect documentation and designing a system that is not intuitive to use and requires following a manual to use it correctly.
Some companies do not care to keep internal and customer documentation up to date.
I follow the fool-proof principle (aka defensive design) that the system should be designed in a way that is difficult to use incorrectly and easy/intuitive to use.
|
|
|
|
|
Shao Voon Wong wrote: I follow the fool-proof principle (aka defensive design) that the system should be designed in a way that is difficult to use incorrectly and easy/intuitive to use. Fail safe systems fail by failing to fail fail safe.
|
|
|
|
|
The Boeing 737 Max MCAS bug, for which the end-users (pilots) took the initial blame.
|
|
|
|
|
Well.... expensive and deadly enough....
|
|
|
|