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?

  • 162
    You aren't being paid to lie. And telling a client that something is "technically impossible" makes you look stupid. Commented Nov 22, 2016 at 13:13
  • 240
    You should write to your client that some users might just click OK without thinking. Don't just tell them. You'll have a proof that the client was informed of the issue.
    – user48138
    Commented Nov 22, 2016 at 13:17
  • 39
    This totally sounds like a XY Problem. Rather than doing what the client thinks is a good solution, you need to solve their original problem. Ask this question on UX.SE, you will most certainly get something good there.
    – Masked Man
    Commented Nov 23, 2016 at 8:46
  • 6
    @MaskedMan, possibly, but not clear. Maybe the client is demanding it be (inappropriately) easy to perform a task, which would be fundamentally at odds with doing the task safely. In other words, the client's view of what the "problem" is is wrong, but still, they are the client so they drive the work. Even if it is an XY problem, it may be outside the OP's control if the client is dictating design decisions. (I don't disagree with the suggestion to ask on UX; it's a good idea. But I still see this as primarily a workplace question, most likely).
    – user45590
    Commented Nov 23, 2016 at 11:28
  • 5
    @dan1111 I still think this is a bad UX issue. Example, clients are listed in alphabetical order in a drop down menu. Most common client's name starts with Y. Hence, the user has to scroll all the way down all the time. Client rightly sees this as a problem. Naturally you cannot expect client to know UX design principles, so they are fixated on "wouldn't it be good if client Y is selected by default so we don't have to scroll?" Unless the client is a complete idiot, a better UX which addresses their pain point will definitely satisfy them, even if the solution differs from what they asked.
    – Masked Man
    Commented Nov 23, 2016 at 13:08

14 Answers 14


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.

  • 49
    I would just add to make sure to have in writing your misgivings on what implementing this change could cause. This just serves to limit your liability if anything bad actually happens because of it and they try to blame it on you, so make sure to email them your concerns (and try to get them to reply to the email saying they want you to do it anyway).
    – yitzih
    Commented Nov 22, 2016 at 17:56
  • 13
    Hmm I'm unsure about the "it is generally not a good idea to lie to anyone". I'm a bit of a fan of unimportant lies which simplify ones life (for example if someone asks me to fix their printer I will often say I don't know how to). But yes, lets save that discussion for elsewhere online ๐Ÿ™‚
    – Tim
    Commented Nov 22, 2016 at 22:33
  • @Tim Agreed about potentially useful/good(?) lies at appropriate circumstances. Lying to customers, though, seems a bad idea, especially in a case like the current one where any competent programmer could probably refute it easily. Commented Nov 23, 2016 at 2:40
  • 6
    "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." xkcd.com/1425
    – Celos
    Commented Nov 23, 2016 at 7:35
  • 3
    In this case the problem is not yours, and here's why: 1. An employee who clicks 'OK' to transfer thousands of Euros to a (reasonably random) company without thinking is the primary problem. 2. Your UX enables that. 3. Your customer requested that UX even against your suggestion. This is not a customer asking you to do something illegal. It's not a customer asking you to do something unethical. It's a customer, who's been fairly warned, asking you to do something suboptimal. As long as you've registered your complaints in writing/email you're all set. Commented Nov 23, 2016 at 13:47

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.

  • 2
    +1, definitely should tell them the risks so they can make an informed decision, then leave the decision up to them.
    – mikeazo
    Commented Nov 22, 2016 at 12:57
  • 129
    ...and get their response in writing. CYA and make sure that when that particular failure mode rears its head you have a legal "I told you so". Commented Nov 22, 2016 at 13:31
  • 14
    +1 IT people, in general, tend to be highly intelligent, so there is a tendency to be dismissive of the abilities of others. We have to remember that we can't make decisions for others based on the fact that we are smart. Our job, however is to propose and develop solutions, not to make decisions for others. Commented Nov 22, 2016 at 13:51
  • 1
    @alephzero You're right, and I'm getting old. 30+ years ago, you had to actually know what you were doing, or you could get some very interesting results from your JCL or C code, and nobody would dare call you a "code monkey". Today.... not so muchj Commented Nov 22, 2016 at 17:28
  • 2
    @Mindwin what makes you think I do? The "not a child" part refers to "thus allowed to make their own decisions", not the lying part.
    – Erik
    Commented Nov 22, 2016 at 18:17

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.

  • 13
    Yes, a risk assessment is professional, lying isn't
    – Kilisi
    Commented Nov 22, 2016 at 12:57
  • 5
    "Have them write something like...", that feels childish. You definitely what to document that this was their decision, but making them write this out, I'm not so sure.
    – mikeazo
    Commented Nov 22, 2016 at 12:58
  • 35
    @mikeazo Have you ever been in that position? Bosses have told me "Did I say that? I cannot remember. I never said that." more often than I care to remember. You can document all you want, but it's only their own words that will make them remember. It does not need to be written in the blood of their firstborn. A simple email replying to the risk saying "I know, do it anyway." is perfectly fine. As long as they wrote them.
    – nvoigt
    Commented Nov 22, 2016 at 13:13
  • 2
    Sound advice, and the only professional option. Simply implementing it will allow for the nightmare scenario he envisions. Lying will make him look foolish or incompetent down the line when what he claims to be impossible is shown not to be. Doing a risk analysis, putting it in writing, and having the client acknowledge the risk is the only thing that protects him both legally and professionally. Excellent answer. Commented Nov 22, 2016 at 13:42
  • 12
    It is critical that he acknowledge the risk in writing. There is potential for legal issues to arise from this and you must protect yourself. Further by asking for a written confirmation that he is fully aware of the risk, many people will realize that they could be in legal trouble if the risk happens. I have seen this approach make people back off of particularly stupid ideas when they found out they would own the risk.
    – HLGEM
    Commented Nov 22, 2016 at 14:47

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.

  • 2
    My bank gives me 12 hours to reverse any transaction I make. This is the right approach and has been discussed on UX.se with regard to having a facility to undelete recently deleted files being a good idea. Rather than lie to his customer, OP should point out the risks and offer to implement a 5-minute delay and back button to make it easy to stop the transaction before it is performed. A large proportion of errors where the user clicks rashly are noted and regretted immediately, and can be caught in this way. Commented Nov 22, 2016 at 21:15
  • 5
    It is always your call to make unless perhaps it's a clearly contracted action. (And even then ethical decisions might be enough to refuse to continue.) Seriously, if your customer asks you to help with, say, embezzlement, would you always go along? If not, then is the line always strictly at a point of legal liability? And if not, then how to decide? And selling guns to incompetent customers is definitely an ethical issue for responsible sellers. Selling bad product of any kind is not a recipe for safety. Commented Nov 23, 2016 at 4:30
  • 1
    -1 the first paragraph seems to counsel the OP to just assume the client knows best, which may well be wrong. Often the developer has a much better idea of the implications of a software design choice than the customer. Also, as @user2338816 points out, refusing to do the work is always an option. At some point, one clearly should refuse to do the work (e.g. if they tell you to hack into a competitor's database, or do something that puts lives at risk...). The question is whether this case rises to that level.
    – user45590
    Commented Nov 24, 2016 at 9:53

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.


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.


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.

  • 1
    Actually, a good parent will try to help his children avoid mistakes, but will ultimately allow mistakes to be made for the child to learn from them.
    – Agent_L
    Commented Nov 22, 2016 at 17:07
  • 2
    @Agent_L - What parent would allow their child to make a mistake that might get the child run over by a bus? As I said, the OP is not the customer's parent. It's the customer's responsibility to make sure that they don't get run over by a bus. Commented Nov 22, 2016 at 17:11
  • Getting run over by a bus is quite dramatic example, I thought more of getting fingers burned by playing with matches.
    – Agent_L
    Commented Nov 22, 2016 at 17:21

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.

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.


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.


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.


  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.

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.


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .