Is it OK to lie to a customer to protect them from themselves?

Question

I'm a software developer. A part of the application I'm currently working on is distributing big amounts of money to the clients of my customer.

In the application the users – employees of my customer – have to decide and choose which client gets a certain amount. Based on the information in the system the application could make an educated guess which client is the correct one. But as the information might be wrong or incorrect I can't be 100% certain.

Now the customer has requested to preselect the most probable client, so the user only has to click OK, instead of selecting the client first, if the application guessed correctly.

I fear that, if I implement this, some users would always just click OK, instead of thinking whether the selected client is correct or not. Which would lead to thousands of Euros transferred to the wrong clients.

Knowing my customer, he won't listen to my argument. So my only options are implementing this possibly harmful change, or lying to the customer, telling him, that this is technically impossible.

Is it professional/ethical to lie to a customer to protect them from harming themselves, if they don't listen to an argument, in this or other scenarios?

Answer 1

You should never lie to a customer. For that matter it is generally not a good idea to lie to anyone but that is a broader ethical issue for further consideration in a different venue.

Trying to say that it is "impossible for the programming" to make the likely choice guess would stand out as so obviously wrong that you should not even go there. If the customer can surmise the scenario from the data at hand then it is possible for a program to be written to come to the same conclusions.

In my work when I encounter similar situations I will normally implement what the customer desires but will also help them see that there may need to be additional steps taken to reduce mistakes. In this scenario the customer is suggesting something that will improve work flow productivity. This can help save time pawing through a customer list dialog to manually select the specific one. On the other hand once the commit is made to post the transaction the programming could note that the auto filled field choice has been used and that the amount total is large and then pop up an "are you sure" confirmation that shows pertinent data. A quick click of confirmation hardly interrupts the work flow at all.

So in conclusion - work with the customer to find good solutions instead of trying to make your own judgements of what is right or wrong with their ideas.

Answer 2

It's not professional to lie to your client to protect them from harming themselves. Your client is not a child, they are an adult and are expected to be allowed to make their own decisions in life. Including ones that will cost them reputation, money, or their company.

Think about it if it were professional/ethical to do this. Would you want your doctor to lie to you about the risks of smoking to "protect you from yourself"? Would you want your mechanic to lie to you about the risks of not fixing your broken watchamacallit to "protect you from yourself"?

I think you would want it to be your own, informed decision. And I think your client will want the same.

Answer 3

The professionally/ethically correct way of doing this would be to accurately inform your customer about all risks. Then let him or her weight these risks and let them make an informed decision. You are not in the business of making risk assessments or business decisions. That's their job. You don't want them to tell you how to program, don't tell them how to do their job either.

Prepare a statement where it it clear that you see that risk, in simple terms so they can understand it. If you want to underline the importance of this risk, you can try to make them sign off on it. Have them write something like "I read and understood this risk, I want it implemented anyway."

If the only risk is the business losing money, then this is all you can or should do. It's probably a whole different can of worms if the business owner is risking something that does not belong to him (for example client's health), but that is a different question and should go to a legal professional.

Answer 4

This is not your call to make. Maybe the client has well-trained employees which a taught to pay attention. Maybe the error is not as catastrophic as you imagine (e.g. my bank gives me 12 hours to reverse any transaction I make, and unusually important transfers may take several days to clear). Don't assume your client is stupid to the point you need to protect him from himself.

Informing your client about the problem was a good thing to do. Better yet, you may suggest solutions which in your opinion may reduce the risk. For example, you can suggest that the program presents a list where clients are sorted by relevance, but the user still has to click on the first row to confirm. But you'll have to let him decide.

Ultimately, you can't sell someone a gun and make sure they won't shoot themselves in the foot. Selling bad guns is not a recipe for safety.

Answer 5

Absolutely, positively, never lie to a customer. Period. The only exception is to protect yourself from deliberately harmful (to you) actions by the customer, but in such case you're better off ending the relationship since you can't trust them.

(I had one client who wouldn't take my advice, and I refused their money because I couldn't take the liability. They folded six months later.)

Users make errors all the time. They must have business processes for dealing with this type of error. Ask what those are and how the change fits in to that.

I'd also highly encourage the "top 3" or "top 5" or "top whatever-the-customer-wants" option. When asking about their business practices to correct these errors, suggest that your understanding of human neurology and psychology suggests that giving only one option will result in an increased error rate since the top suggestion will not always be the right one but the more often it's right the more people will assume it's right. In other words, the better your first guess is, the more often you'll get errors because people trust it even when it's wrong.

Answer 6

No, it's not okay to lie, because your reputation is important. Guard it with your life. Reputation has to do with things that you do, but also things that you allow your client to do that may cost you later on, in terms of professional liability.

You can't be forced to do the work. Remember that.

You can also specify the conditions under which you'll be willing to do the work. In this case, you have a high-risk feature that your client wants to be done in a certain way. To an extent, that's fine. Your client's not asking for anything illegal or unethical - just stupid. So here's what you do:

• Functional requirements. YOU document the specific functionality that the client is requesting, as you understand it.
• Risk assessment. Again, YOU document the potential risks that you foresee that the client may encounter once this system goes live
• Waiver. This is the important part. Before you do the work, have your client sign a waiver of liability for anything that goes wrong as a result of you implementing the functionality requirements you outlined in the first step. It should indemnify - specifically: you, by name; any others in your company working on this piece, by name; the company; your insurance company (I'm assuming you have insurance!) against any legal claims. Have your waiver reviewed by an attorney and make sure it's airtight. Don't do the work unless the client signs off.

If you skip these critical steps, you may be open to a lot of financial exposure as a result.

Answer 7

You already explained the risks to the customer and the customer insisted that you do things their way.

Do it their way. In this case, go by the Golden Rule: he who has the gold makes the rules. The customer pays for your services and as long as they pay, your services is what they get. This transactional relationship ends the minute the customer stops paying.

You are the customer's contractor. You are not the customer's baby sitter or parent. Customers have the right to over ride your objections and make their own wrong headed decisions. Object for the record, and go into CYA mode by documenting your objection.

DO NOT ever lie to the customer for whatever reason, because if your lie ever gets documented, it will pursue you where ever you go. Your personal and professional credibility will be shot and this will impact on your ability to make a living.

Protecting people from themselves is just not worth it, especially if the result will be that you will be blamed for anything that goes wrong. And the more you defend yourself, the more dodgy you look no matter how good or sound your arguments are. You are not a missionary, you are not a do-gooder, you are not in the business of saving souls and you certainly don't want to end up as a martyr - in particular, a martyr for a cause you don't believe in. Forget it.

Answer 8

Do not lie to them. Tell them you can do what they want you to do, but you do not want to do it. Tell them why and suggest different, more fool-proof (or lazy-proof) solution(s).

Knowing my customer, he won't listen to my argument.

Maybe, you are using language they cannot understand. I suppose they are focused to economics, so profits, risks and fees are arguments they would understand.

1. Use their actual workflow, workflow they demand and workflow you suggest.
2. Estimate the time to process, say, 1 000 transactions and multiply it with wage of Average Joe.
3. Calculate saves of their and your improvements with respect to actual workflow.
4. Estimate the probability of false guess and plausibility of wrong transaction.
5. Estimate the financial loss coming from the wrong transaction - wasted money, damaged reputation, lost contractor,...
6. Multiply financial loss by its probability and 1 000 (sample size)
7. Compare saves from step 3. and losses from 6. Emphasize, that the estimated losses are the minimum losses to be expected.
8. Make it all written and force them to sign "I have read and understood" claim. Discus it with your favourite lawyer how to word the claim to be creative-lawyer-proof.
9. Make them agree that you take responsibility for the feature to work as they demanded but you do not take any responsibility for the results of the feature.
10. If they still want to have this crappy feature and it ruined their bussiness, they deserved it. And you have a paper to defend yourself.

Answer 9

Don't lie, rather agree with the customer's need for efficiency and suggest implementation safeguards for the action:

• add the transaction to a queue, giving the user time to reflect and change or delete the transaction

• support linear undo, as would be found in tranactional finance products

Ideally, customers would catch these scenarios and have established protocols for dealing with them. When they don't, an architect should see them and develop functional protocols. When a developer catches the loophole, there's really no other choices than raising a flag, armchair architecting, or just building the damn thing.

Answer 10

I agree with all of the "don't lie to the customer" answers, but have a perhaps different solution: could you -- without taking too much development effort -- track the decisions made? How often is the default accepted? By amount of transfer, by time of day, by user, etc. That might give them a way to make decisions down the road -- either to modify the software or to increase training, etc.

You can't save them from making poor subject-matter decisions, but you can provide them with enough information that they can tell: a) if their decision is not working as they expect, and b) what mistakes are due to users and what mistakes are due to the default-choosing algorithm.

Just a thought.

Answer 11

I would never lie to the customer. Instead you should give them an alternative. The best alternative that I can think of would be having the user type in the clients name instead of just pressing "ok". This forces the user to use their brain rather and prevents some sort of clicking error. You can even give them a confirmation page after they've typed in the clients name where the click "ok" and give them a chance to change their answer, if needed. Heres a list for you, though a sequence diagram would work much better.

Process:

1. The user clicks enters a page that decides which client is most probable
2. The page presents the client name to the user, but the user needs to type in the clients name to continue. Optionally, they can click "No" (or a button with some other text) to enter a different clients name of the program was incorrect. If they click no, they manually type of the client name, the system matches it with an existing client or raises an exception if no client matches and handles this exception gracefully.
3. After typing the name, the client clicks 'ok'.
4. This brings the client to a confirmation page, which tells them which client they are sending money to. They click 'ok' here and the money is send.

Answer 12

Explain your concerns with their suggested UI design. Saving themselves from their mistakes by explaining them and helping them solve the problem differently is probably part your job as an expert. Saving them from themselves by lying is less useful in a lot of ways. The biggest is that it doesn't clue them in that it's dangerous, so they might just find someone else to implement their bad idea.

If lives are at stake and you think your client is going to do something that will seriously endanger other people (or the environment, or whatever), then maybe stall them while you contact an authority. If they're only going to harm themselves, then just do your best to explain the potential for harm.

---

As an example of how to solve this problem in a way that's less likely to lead to badness:

Instead of popping up just one best-match with the highest likelihood according to your heuristic, pop up the top 3.

You might or might not want to show some kind of "confidence level" in your guess, like selection A: 95, selection B: 44, selection C: 33. You might want to highlight it when the second-highest possibility is close to the highest, like A: 45, B: 40, C: 30. (IDK if you want to scale them to percentage probabilities, or show them as independent scores from your heuristic.)

---

As @bishop points out, queueing the transaction for a short time will allow an undo, since it's easy to realize you clicked the wrong thing as you click it if you're operating partly on auto-pilot.

---

PS, this part of the answer is a workaround for this specific case, and isn't part of the general-case answer.

Answer 13

Don't lie to the customer. Explain to them what your fears are about this feature.

If you feel it is appropriate, you may decide to personally refuse to implement this feature. Yes it's the client choice whether they want it or not, but its also your choice as a programmer whether you want to develop it. Of course you will have to consider contract terms carefully if you opt to refuse to do what the client wants in this case.

In the talk "not just code monkeys", Martin Fowler argued that programmers should have more regard to the consequences of their work.

If programmers had a stronger professional membership organisation, as professions such as lawyers, doctors, architects and engineers do, we would be in a stronger position to refuse some requests on the basis that they are contrary to professional standards.

Answer 14

This question is based directly on CS and ethics. This is probably a poor answer for workplace, but a good answer if this question was asked on stackoverflow or CS. I claim the question is a poor fit to workplace and the answer is a good fit to the question. As a consequence of this, the answer applies to the exact question asked but has very limited scope to questions that appear to match.

You are right to say the guess would not be 100% accurate. Let us say on the other hand we can do better than most humans almost all of the time. (If this is not the case the rest of this answer is complete hogwash.)

In order to deal with the situation you need a confidence function that says how good your guess is. This is not a trivial thing to obtain, but almost always exists. The idea is to know with confidence how reliable your guess is in every given case. If your guess is sufficiently reliable display the guess. If the guess is highly reliable default-select the guess so that OK works by itself. If your guess is unreliable don't display it.

For reasons involving liability I favor setting reliability to show at 80% and reliable to default at 99% to 99.9%. Assumption: 1% of manual data entry is incorrect. In addition, codenoir is very correct about waiver. You must not be liable for the user's bad decisions. Even if you can be much better than humans almost all the time you cannot afford to take liability involved. People do not tolerate machine error in court as much as they do human error.