You Cant Always Get What You Want

But you'll find sometime - you get what you need. (MickJagger?)

You know, if you give people what they need, rather than what they want, they often like it better, and over time learn to trust you. After all, you are the professional. Users want bad things because they don't have the knowledge to know about the alternatives, or haven't even seen an alternative. If you were an engineer, would you give them cheap weak concrete just because they wanted it? HELL NO, because you're supposed to be a professional. The same applies to software. Don't let a user force you to build bad software when you know there's a better way.

This is a very incomplete analysis, even though it is an admirable thought. For instance, you may have a legal obligation to give the client what they want, not what (you think) they need -- this is very frequent, not hypothetical, although the average worker bee is typically insulated from such legal issues.

I'd venture to say that "most" biz apps don't face such legal requirements, which is the case I was referring to. I'm sure there are many that do, but I bet there are far more that don't.

See a somewhat more detailed analysis on DoTheMostComplicatedThingThatCouldPossiblyWork (the discussion in question is on that page sort of accidentally, not because it is equivalent to that page title).

In cases I've seen, what the developer knew needed to be done, was usually simpler and cheaper than what the user thought they needed. Users are the ones that pile on useless feature after useless feature that eventually kills a program. We don't exactly like making extra work for ourselves, and it's programmers that tend to like simpler software. See google for an excellent example of this. So it's quite easy to do the right things, and keep saying the word prototype to keep the users off your back, until they realize that the prototype is just what they need. It may be evil, but users don't know how software is written, so it's quite easy to tell them this or that needs to come first, so you can prototype this or that subsystem. It doesn't take much talking to confuse them into leaving you alone. You can do so in a way that assumes intelligence on their part, forcing them to back off because they don't want you to know they haven't a clue what you're talking about, and you can do so without sounding overly technical, or sounding like you're doing it on purpose. In the end, as a programmer, your job is to deliver successful software, and if skillful manipulation of the user helps accomplish that goal, then so be it.

(A) first responses are basically "oh, well, there was context for this page that we knew but you couldn't possibly have known, because this was moved from somewhere else, but we didn't mention it." Well, then, give needed context, eh?

(B) rest of response shows that respondee didn't bother to read referenced page DoTheMostComplicatedThingThatCouldPossiblyWork -- must it be quoted in its entirety here?

Hmm.. I did read it, but didn't think that means the discussion was ended, I felt like commenting more. Much of that discussion assumes the we're putting in extra stuff that the customer doesn't want or didn't ask for, or just makes us feel better by making it more complicated. I'm saying the opposite, take things out, trim it down, simplify it, because that's what they need. I'll read again tomorrow when I'm not so tired, maybe I overlooked something.

I work in an industry where a requirement is published, along with an "invitation to tender". It's always clear that the people who wrote the requirement have done some homework, looked at the glossy brochures, and put together a "requirement" that simply lists everything that sounds good and exciting from all of them. In order to tender you must submit a "compliance matrix", in which you put a tick or cross against each "requirement". Largely speaking, if you have any crosses, then you're not in the bidding.

But you can't just tick all the boxes and then supply what you think the customer needs. When delivered the software will go through a Site Acceptance Test (SAT) which will explicitly test each of those ticks you put there. Failure to comply results in financial penalties and a legal obligation to supply the missing features.

Tell me how your thoughts apply about lying to the customer and then eventually giving them what you have decided they need, rather than what they have ordered and in many cases paid for.

Obviously this approach doesn't work in such an industry. How many times must I say "most" biz apps don't face such legal requirements. Use what works, if this can't work for you, then ignore it. Nor did I ever say lie to the customer, expectations can be changed, customers can be educated and made to want something different than what they first ask for. Contracts and legal requirements are just "things", "people" run the show, and people can be induced to change these "things". You don't work for a contract or a company, you work for a person. Somewhere at some level, a person has the power to fix that silly contract, you just have to find them and educate them. Is this always possible... NO, doesn't mean you can't try.

[The other page says in part "If we're good enough at communicating, we may find ways to persuade the customer to want what they also need; no more and no less".]

[I don't believe that any other approach to "give them what they need, not what they want", can ever work reliably (although one might get lucky), because any other approach is inherently deceptive, fraudulent, condescending, etc.]

[Now, if you are working for a pointy haired boss, maybe you have to be deceptive with him in order to give your company what it actually needs. This is dangerous, but people talk about such things all the time, so it's obviously common. But it is still deceptive, even if, in that case, an arguably ethical kind of deception, due to the presumption that one's first duty is to the company.]

[An immediate problem with the above is that the boss is not always the one in the wrong. Programmers will often think they know better and the boss is an idiot -- sometimes they're right, sometimes they're not.]

[In any case, that's not the first strategy of choice. Persuading people to want what they need is the first strategy of choice.]