[...]

[...]

   I think there's another relevant thing that IT people do: believe that
sometimes client is unable to express what they want.

   There's a lot of absolutes being thrown about in this thread, so I'd
like to address that before coming back to my main point. *USUALLY* the IT
person in charge of a given IT project knows more about computers than the
client paying for the project. Usually. Not always. Usually the IT person
knows more about programming than the client; but not always. Usually the
IT person knows more about software design than the client; but not
always.

   Sometimes, the client is a really smart
programmer/software-architect/engineer/whatever who just happens to be
hiring someone to do an IT project for them, and the person they are
hiring is less skilled than they are. It could simply be that the client
has more important projects to take care of, and just needs some bodies to
finish off the easy parts of a nearly complete project. Here, the client
knows more about computers/programming/etc. than the programmer.

   For the rest of this post, I'm going to be talking about the more
common case where the client is someone who knows very little about
computers, and just wants to throw money at someone who'll take care of
all the details, as long as they get what they want.

   But again, sometimes the client is unable to express what they want.
And sometimes one of the IT people has, as a primary function, to extract
from the client exactly what it is that they want specifically because
clients have so much trouble expressing what they want.

   Let's say the client, familiar with math, statistics, game design,
literature, etc. but not very familiar with computer science, says "I want
to make a game, and as a first step I want a random number generator that
will give me a uniform distribution of all possible values between 0 and
1". Well, the client is almost surely mistaken. The vast majority of
numbers between 0 and 1 are uncomputable (that is, they have an
Kolmogorov-Chaitin complexity of infinity, and cannot possibly be
generated by a Turing Machine). Much more probably, what the client
"really" wants is for all IEEE double values between 0 and 1 being
generated with equal probability.

   So now, the IT person, who has been sent as a liaison/interpreter
between the clients and the programming team, has a choice of what to do.
Do they tell the client that their request as stated is impossible to
satisfy, lecture them about the size of the set of integers and reals,
IEEE standards, Turing Completeness and so on, or do they just assume they
know better than the user what they really want, and jot down "Random
Number Generator, 0.0 <-> 1.0" on their task list, and move on to the next
set of requirements?

   Again, there's a bit of context involved: If the client's project has
something to do with encryption or online gambling or stuff like that,
then you might need to probe the for more details, such as whether a
"truly random" generator is required (and you might get into philosophical
debates about the definition of "truly random"), or if whether Java's
built in pseudo-random number generator is "good enough". But if they're
just making a single player game, you can generally assume that a PRNG is
what the client really wants.

   A part of "doing what the customer wants" is usually "don't bug the
client too much with the details". If the client knew all the details of
how to do what they wanted to do, they'd probably just do it themselves
(with the exceptions mentioned above).

   Clients (and people in general) also tend not to be very good at
judging what parts of their request require a lot of detail, and what
parts are best left up to the whims of the developers.

   The end goal of everybody is to become happier. If you tell a software
developer to write software that will make the client happy, the software
developer is probably going to complain that the request is too vague, and
outside of the dev's area of expertise. The client needs to do some
analysis of their own to determine (perhaps correctly, perhaps
incorrectly) that being rich will make them happy, that having more
profits and fewer expenses will make them rich, and that it must be
possible software will increase profits and reduce expenses. Now we're
getting closer to the point where a software dev can come in handy.

   At the other extreme, the client may give requirements that are overly
specific, that they don't really care about, and that make the developer's
life more difficult, simply because they felt that they should give lots
of specific details (perhaps because in the past, they had received
complaints that their requirements were too vague).

   As an example of this, a client may state that they want an HTML
document to be generated which has very specific formatting requirements
when printed; for example, with a specific footer appearing on the first
page, and a different footer appearing at the bottom of every other page.

   In theory, this is possible: We could try develop some sort of spyware
which would secretly get executed on the end user's computer, accurately
detect the browser and OS being used (can't trust the agent-string sent
in), and the size of the paper in the printer's tray, and force-configure
the printer margins to be a specific setting (e.g. 0.3 inches), and then
use lots of <div> tags and CSS hacks to exactly position elements on a
pixel-by-pixel basis. We'd have to generate different HTML and CSS
combinations for every OS, browser and paper size combination (and there
are over 500 versions of Firefox for Windows alone, so this is quite an
explosive combinatorics equation). If we're going to be installing spyware
on the user's computer, why don't we just have the spyware directly
communicate with the printer, you ask? Well, the user *said* they wanted
an HTML document generated, and for that HTML document to get printed.

   Instead, we asked them if we could just generate the document as PDF
instead of HTML. It turns out that we could, and the client didn't really
care either way. Made our lives a lot easier.

   - Oliver