Recently there was a SO question asking how to implement a feature which blocked users from copying text from a page in their browser. There were many negative comments on this feature, both because it's not practically possible to implement effectively and because it will interfere with the users' experience?
What's a programmer to do in these sorts of situations in dealing with their clients or employers?
Try to understand why the client wants to implement such a bad idea and suggest alternatives.
To tackle the issue, I usually need to take a step back. This issue usually arises because client/customer wants to accomplish something general (ie make sure the end-user knows what they're entering into a webpage) and has come up with a specific solution (ie, don't let them copy/paste) to their perceived problem. The way to solve it is to ask more questions to figure out what the customer actually wants to accomplish. "Why" is a powerful question -- as is "What is the underlying problem you're trying to address?"
You could be cynical, in the case of the client, and just use the hours you need to implement it and thereby give your company a lot of money. The other way I see is to ask the client why he need it, and tell him about the downsides (hard to implement, negative user experience, etc.) and then let the client take a last decision to if he really want you to implement it.
Ask the customer what problem this feature is supposed solve or correct. Many times the problem is real and can be solved easily, they just have some wacky notion as to how it should be solved. Usually based on bad second hand information.
Once you know the problem then you should be able to suggest mulitple practical solutions.
You will occassionaly run into the client who thinks he/she knows more than you do and will insist on some wacky solution to a non-problem or worse. Unless you really need the money or want the headache, run away as fast as you can.
What's a programmer to do?
Most of these odd / bad idea / hard-to-implement / impractical requirements typically have a deeper, possibly misguided, but none the less real (to the customer) reason for being. By better understanding this root reason, one is in a better position to :
I think you should give your client a list of advatages and disadvatages of the feature, and then let him decide which way he wanna go.
Personally, I would be as honest as possible. I would provide the benefits/drawbacks of the feature and make sure the customer has all of the information required to make a good decision.
Ultimately, they are the one paying for it... but you have to at least make sure they are informed when making these kinds of decisions. Of course, you also need to decide if you want to be associated with a solution that you are opposed to... and I think that's something each individual has to decide on their own.
The best you can do is to try to explain as clearly as possible why the requested feature is a bad idea. Don't go overboard , as pointing out obscure flaws/issues could do more harm than good (speaking from personal experience). Additionally, if it's clear why the feature in question is being requested you could offer alternative solutions that address the base issue (assuming it isn't a fundamentally bad idea).
Unfortunately, as long as you want to get paid, you are agreeing to do things you disagree with. As long as you have made an honest effort to communicate (preferably well documented) your concerns there is not much you can do. If you're lucky your client/employer will be reasonable and see the problem.
If you can explain why it will be very costly to implement the feature that may also help. For example, if someone said that that feature will cost you $1,000,000 it may be surprising how frequently someone will take back a request because they don't want to spend that much to get it.
Give it a very high price tag. (if you really think about it, usually wrong architecture leads to high maintenance cost, so it's only fair :-) )
