I have worked with several companies that have very different views on this.  Most of them draw a line in the sand when it comes to giving customers access to the development team, and they simply refuse to let the customers near the developers.

I actually see both sides of this.  There are many reasons why not to, such as politics, communication, distraction, etc.  The developers’ main job is to write code,and many companies just don’t see the value in letting them do anything butwrite code in a relative vacuum.

On the other hand, customers feel involved and part of the process when they can actually speak with the developers of the product they paid money for.  Not only is it a great source of feedback forthe developer to hear firsthand what issues a customer may be having, but it is also an opportunity for customers to share ideas based on real world use cases.  There is no doubt that some of the best products I have been involved with have come from the developers having some sort of customer interaction.

How many software developers that write and support a group of applications actually know how their products are used at a customer site?  Based on my experience, I suppose it is fair to guess 50% of them, but I have no real data to back this up.  For the most part, the developers are focusing on the coding tasks they have been given and try to keep the versions and bugs under control.

I have always promoted conversation between developers and customers.  I also firmly believe in exposing the developers to various customer locations – even if for a day or two just so they can see how that particular customer is using their software.  A customer site beats the QA lab any day of the week in my opinion.

Of course this interaction must be managed as to not cause delays in actual codework, but the more a developer understands how their application is being used,the better the product will become and the happier your customers will be.