# Long issues are normally handed off (they are normally issues that can’t be reproduced and require communication with the customer). Hard issues are solved by pairing

# Developers who can’t communicate with our customers should grow up and face it. The code is being used by customers and we want an open communication channel.

Simon Jones from the extreme programing mailing list suggests:

1. Have a dedicated person for helping users use the application
2. When defects are found – they are top priority (i.e. halts the iteration)
3. When ’sub-optimal’ features are highlighted – they should be written as a new feature (story).

This might work well in a perfect environment, but practically it doesn’t really work. Here is why.

1. Helping users use the application also might point to a missing feature. 1 and 2 are mixed.

2. It is nearly impossible to know up front if the issue is a real defect or a ’sub-optimal’ feature. Handling support is a different mind frame because of the communication with the customer, and it takes time to pinpoint the problem (and find workarounds)

3. Developers must understand how users are using their application and having someone dedicated will lose this contact.

4. Even if defects are considered top priority, there is no mechanism in agile environments that ‘allows’ pushing these issues into the current iteration

Having support and getting input from the customers is not a sign that the software is bad, it is actually a sign that the software is being more widely adopted and is being used in more egde case scenarios that where not considered with priority at the time of release.

#thats something that still need to be fine tuned. But luckily most cases are not of this type.

# Being a good developer requires many skills. I would like to think that even the skills that you mentioned can be learned and improved over time. I also think that these skills are really mandatory for all programmers. Being a good tech support is not beyond any programmer abilities (in most cases).

# More often than not, the developers have their different domains of expertise. What if I receive an issue which I am not familiar with when I am wearing the technical support hat? Should I get to the developers in charge or I try to solve the problem myself? I may not be able to solve the problem even if I want to. Or if I pass the issue to the developers in charge, then it becomes his problem. This, seems to me, is defeating the purpose of rotating the technical support. The very point of rotating the technical support hat is to let only one person worry about answering customer’s call and let the rest focus on development tasks.
# What if an issue requires a long time to solve? Then multiple developers may be involved, and there is a waste of the developer’s time because each of them need to update themselves with the latest development. But if you have a dedicated person to follow through a problem, then you do not have to spend time passing the cases around and updating everyone involved all the time.
# Developers like coding, disdain technical support. They may not excel on answering customer questions although they are good coders. How to evaluate these developers? Answering customer’s questions require a good balance of technical skills, people skills and language skills. Developers may not have problems on technical things, but some may have a hard time expressing their ideas in terms of English or any other languages; some may not have the patience to be a good tech support guy. How do you deal with these people?

http://itscommonsensestupid.blogspot.com/2007/12/rotating-support-among-developers.html