It is easy for developers to get the feeling that SoftwareIsReallyPointless.  They are assigned tasks by managers, they talk to "customers" or "clients" who want all sorts of things that don't seem to make sense, and they spend much of their time huddled with other developers trying to figure out why some stupid little thing doesn't work.

The OnsiteCustomer or CustomerProxy is often not the person who will be using the system.  It is generally a marketing person or a high-level manager who does not really understand the task that the system is supposed to be improving.  They have authority to approve UserStories, and they may have some good ideas, but they often are clueless about what the actual users really need.

'''Therefore,''' meet the actual users of the system.  This is useful before the software is developed, because you can find out what their actual task is (rather than the abstraction presented to you by managers) and you can find out what features are really needed, and how complex they need to be.  It is also useful after delivery of the software, as the developers and users can give each other feedback.

In addition to the benefits of having a more usable system, this generally improves developer morale.  Seeing the system actually being used, and seeing happy users, goes a long way toward making their jobs seem valuable.

'''But,''' there are a few potential drawbacks.  If users know who you are, they might call you directly when they have problems that need fixing.  You might get into arguments with the "customer" and your managers about what is ''really'' needed.  And if the delivered system is bad, meeting with its users can be very unpleasant.

----

See also: DontCallPeopleUsers (which ironically agrees with the spirit of this page but not its letter)