IT professionals are experts who are trusted with the IT assets of a business or organisation. As trusted professionals we have responsibilities that extend beyond things that a non-IT customer can be expected to understand or be aware of. So I think the proper relationship between an IT professional and his internal/external customers is more like that between a doctor and patient than a servant and master. Am I right?

Here's an analogy to think about. A patient insists that his leg needs to be amputated. His doctor disagrees but the patient cannot be persuaded. Should the doctor amputate the leg just to satisfy the patient?

Another analogy. A customer wants a civil engineer to build a bridge to an unsafe design. Even when the engineer explains that it is unsafe the customer doesn't believe him. Should the engineer build the bridge anyway?

I think the right answer in both these analogies is NO. The medical professional and engineering professional are supposed to be in a position of trust and ought to exercise their own judgement, even in the face of patient/customer disapproval. Shouldn't the same apply to IT professionals when the IT professional is qualified to make the decision but his customer is not?

  • 2
    At a conference I once heard a speaker say "Whatever you do, don't let the customer have direct access to your lead programmer. If you do they will literally rape him." I think this would be both the wrong relationship between a software developer and the customer and the worst use of literally I've ever heard. Dec 16, 2010 at 15:38
  • And here at my work it's a founding principle that the customer always has direct access to the lead programmer! Dec 16, 2010 at 17:48
  • For small values of "literally", presumably?
    – Mawg
    Mar 24, 2015 at 10:38

7 Answers 7


It's a bit more complicated than in your examples. That's because in many cases, the software developer is an expert in IT-related things (i.e. programming, database design etc.), but the business customer is an expert in the problem domain. In such cases, the proper relationship is that of two experts in different fields that work together to create a good solution.

Anyway, like any good craftsman, the software developer is obliged to warn the customer when the customers wants things that are inappropriate. If you ask your painter and decorator to wallpaper the bathroom, he is also obliged to warn you that this won't work out well. But when the client stubbornly insist on his bad idea, it's ok to have him sign a "you have been explicitely warned" form and implement what he wants (as long as there is no health risk, legal risk etc. in doing that).

  • 1
    +1 I also think that amputating a leg without reason and building an unsafe bridge is far more dangerous than delivering an application that doesn't match customer's real needs. However, like dportas said, the role of the IT specialist is to warn the customer about that. And then it's just ethics. A good lawyer will not advice his customer to sue the other party if he is sure to loose. (but win his hourly fee)
    – user2567
    Dec 16, 2010 at 9:16
  • 1
    +1 - I've seen at least as many instances of the developer not really understanding the clients business as I have them correctly identifying the client asking for the wrong thing and themselves identifying what's really needed. That is they'll frequently correctly identify that there is a problem with what's been suggested, just their solution is still ultimately flawed. The right approach is mutual respect for each others domain knowledge and an open discussion of the potential problem and potential solutions. Generally customers are willing to listen. Dec 16, 2010 at 15:42
  • 1
    So where do you all work that the "business customer" is actually an expect in the problem domain? Too often I have found that's not the case...
    – CaffGeek
    Oct 25, 2011 at 21:37
  • Chad: In my experience, some software companies concentrate on selling to the top-level management, which then forces the mid-level management to implement whatever sounds good on paper. In such companies, you rarely find "business customers" which are also experts in the problem domain, because there is a tendency that the same manager who signed the deal stays the contact person, whether or not it makes sense. Other companies rather sell to the concerned department, so the primary contact person usually knows his job.
    – user281377
    Oct 26, 2011 at 14:55

In both the doctor and engineer examples, the professional is a consultant refusing to perform a service. In an IT shop, you're not.

We're employees, not consultants, so we're subject to the golden rule: he who gives us gold rules. Programmers who ignore that are being arrogant and foolish. I've heard innumerable complaints about that from businesspeople who are fed up with IT staff who won't explain their decisions to anyone outside their insular priesthood, and who blow off requests everybody outside their organization considers perfectly reasonable. I've seen IT managers sacked over that kind of thing.

As an employee, your equivalent to a consultant refusing to perform a service is covered by a quote from Napoleon Bonaparte:

Every commander responsible for executing a plan that he considers bad or disastrous is criminal. He must point out the flaws, insist that it be changed and at last resort resign rather than be the instrument of the destruction of his own men.

You have to pick your battles. Is what you've been asked to do so heinous and unethical that you'd rather quit? If not, then either explain the problem to the stakeholders and negotiate something reasonable, or just do it.

And don't go doing things you haven't gotten buy-off on. People who do that are called "loose cannons".

Incidentally, I have quit one job because they killed a project and I thought it was a really stupid move. A couple of months after I left, they came to agree with me, and asked me to come back as a contractor to do the project, but I was already committed elsewhere.

  • 2
    Many developer are consultants! I'm one. Dec 16, 2010 at 9:18
  • 1
    I'm a consultant!
    – nvogel
    Dec 16, 2010 at 11:49
  • Moreover, engineers and doctors can be employees. I'm sure every large railroad has civil engineers on payroll, for when they want to build or modify a bridge. Dec 16, 2010 at 15:09
  • 4
    I was a full-time consultant from 1991 to 2006, and returned to it full-time in July. I figure if a client wants to pay me to do something dumb but not unethical or hazardous, and insists over my objections... hey, it's their money to waste. And I've usually found my clients know more about their business than I do, so things they want that seem crazy at first make sense after I understand more. I do find I get asked to do dumb things less as a consultant paid by the hour than as an employee whose overtime is "free" to the employer.
    – Bob Murphy
    Dec 16, 2010 at 22:14

Shouldn't the same apply to IT professionals when the IT professional is qualified to make the decision but his customer is not?

In my opinion YES!

If you are going to have a long relationship with your customer.


Doctors take an oath to 'do no harm' and are legally required to put the best interest of the patient first. A doctor that performed a needless and harmful operation (even if the patient demanded it) would be opening himself up to a malpractice suit and could lose his license.

Similarly, a civil engineer, that is responsible for a construction project, has a legal obligation to ensure that it meets all applicable building codes. As with the doctor, an engineer that does what is suggested in the question, would likely face legal action.

This is very different from the situation of a software developer being asked to do something that they know is impractical. There are no legal ramifications to taking on a project, even if you know it is essentially a waste of money.

That said, a software developer should always provide his best advice on any project. However, if the people paying the bills are unwilling to listen and insist on an unwise course of action, the developer has no moral or legal obligation to refuse.

  • 2
    It could be the case that a software project might put life and limb at risk. As in a medical records database or a control system for an aircraft for example. Much more likely though that there could be ethical or regulatory factors that are the legitimate concern of IT professionals - such as privacy and data protection rules or IP laws.
    – nvogel
    Dec 16, 2010 at 11:44
  • @dportas That is possible but if so there are likely laws and regulations that govern its construction and certification. Clearly you should never break the law for your client. However, this is rarely an issue and, judging by the examples cited by OP, not what was being asked.
    – Kris
    Dec 16, 2010 at 14:43

My suggestion in this situation will be to warn the customer in written communication and keep copy of it (e-mail, agreement anything). If the customer insists it then go ahead and do it (This is sometimes known as disagreement and commit). Just make sure that if any bad thing happens, you should be properly able to defend yourself.


The key difference is licensing. Doctors and civil engineers hold professional licenses, and need them to perform their job and make their living, and they also have legal personal responsibility for more things.

This can put more pressure on doctors and engineers, when pushed towards doing something that may cause them personal and professional risk, but it gives them more push-back, since they can argue that they can't do something because of professional ethics, and that they'll lose their licenses if they do. A threat to fire a civil engineer for refusing to sign off on a plan loses force when the consequence of signing off is that the engineer will lose his or her license, and be unable to work in the field anyway.

This is connected with legal requirements. I can't prescribe many drugs, and if I do certain things to somebody that a doctor can legally do I'd committing a crime. Similarly, most governments around here will not permit a company to build a bridge without a licensed civil engineer approving the design.

There have been proposals to license programmers, but none I'm aware of have ever gone anywhere. It would probably be necessary to have a legal requirement to have licensed programmers to work on projects first, and that isn't happening any time soon. There are professional organizations with codes of ethics comparable to medical or engineering codes, but without any legal force they're more like guides for personal codes of ethics.


I'm not thinking of the ethical dimension, but the proper relationship to the customer/user base can be quite variable depending upon the type of market. Where I work we have a highly technical product, and highly technical users, and the average revenue per customer is fairly high. So our business boundaries are a bit blurry: we have customers and value added resellers who act as consultants, who assist in code checkout and may even submit modules for inclusion into the software. It we were selling a mass market application this model would make no sense whatsoever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.