
If You Want to Write Useful Software, You Have to Do Tech Support - pchristensen
http://nick.typepad.com/blog/2009/06/if-you-want-to-write-useful-software-you-have-to-do-tech-support.html
======
derefr
And the corollary, from the customer's perspective: The best possible person
to get on the phone is a developer with commit access.

~~~
prpon
I would second your thought. I worked for a enterprise software company that
had developers building the product, a maintenance team that fixed bugs and 3
layers of support.

The only people who knew what was going on with a huge product were the
developers who actually wrote it. But you had to go thru so many layers to get
to the developers, irrespective of silver or gold or platinum support. I would
never ever pay for support of another product that comes from a big
corporation.

We went opensource with our products and every developer responded directly to
questions from customers. It made a big difference to the users.

~~~
alain94040
I don't think open source is the particular answer to the problem you state, I
think it's an orthogonal issue.

If you have millions of users who want to ask questions (think of supporting
Microsoft Office), then direct access to developers is a non-starter.

What I have seen work are rotation programs where developers spend some time
as first-line support (maybe 1 week per year). When doing so, they help
educate the rest of the support staff, and they get great exposure to real
users facing real problems.

~~~
derefr
> What I have seen work are rotation programs where developers spend some time
> as first-line support (maybe 1 week per year). When doing so, they help
> educate the rest of the support staff, and they get great exposure to real
> users facing real problems.

This skirts the real issue, though, which is that the person you get on the
line should _have the power_ to fix your problem. Putting developers on first-
line support would only help if they were still _developers_ while they worked
there, with all the same access privileges and tools available to them.

~~~
prpon
One of the reasons often cited for the structure that existed was 'it would
distract developers working on the product from meeting the deliverables'.
There is a role for support on a complex product where user errors often are
the reason for tech support calls.

However, If you have a problem that requires code fixes, I cannot imagine
having to deal with a long line of people who have no power to make those
changes.

~~~
kragen
If a lot of users make the same error, then a fix in the code is required.

------
joshu
This is really good advice. This was an essential part of developing
delicious.

------
tsally
If it's for a product you love (and it should be if you're doing a start up),
it's not tech support. It doesn't even feel remotley close to tech support.
It's just fixing or explaining something that matters a lot to you. Hackers
always want to talk about their pet projects... why not make the customer
happy while doing it. :-)

------
sosuke
I love doing tech support on my own sites, anything for one on one feedback
with my users is very fun to me. If one user has an issue it's likely
affecting others.

On my full time work though I run into the same problems he mentioned and I
make a point to asking the requester (of the feature or project) why they want
to do it or what the user will get out of it so I can see if there are problem
areas or possible improvements as I implement the request. It might irritate
the requester but I feel better knowing I've done a little bit more to make a
good final result.

------
sophacles
I worked in a place where devs were also top-tier tech support. This worked
well, as we got to figure out what the problems were, got to help teach our
users the capabilities of the system, and got to look cool when we fixed a
problem in 2 minutes. This was for an in-house network appliance, so our users
were pretty technical anyway, which definately helped. What did not help tho,
was when the help desk got lazy and started directing tickets to us which had
no place in our laps. Then it all went down hill.

In short, its balancing act.

------
mrduncan
I'm curious what balance others have struck between development and tech
support. I know personally I wouldn't want to be developing something and have
to take a support call (or email) every 15 minutes.

My idea would be to rotate who is "on support" every week or two. This would
ensure everyone does get time doing support without it becoming a hassle and
interruption to getting other things done.

What are your thoughts?

~~~
run4yourlives
You could always force email, like 37Signals.

I don't think there's a one size fits all solution though.

~~~
mrduncan
Good point, although if I remember correctly 37signals has at least one
dedicated support person (possibly more).

~~~
run4yourlives
That's just to answer emails though.

------
io
Summary: Direct communication with users yields better software. Dedicated
tech support often translate poorly from user issues to feature requests.

------
Goronmon
A similar sentiment should be mentioned as a developer looking for feedback
from users when you have to deal with your customer's version of "tech
support". The managers and tech support people are explaining what they think
the problem is that the users are seeing, but when you walk through what the
user is actually doing it's usually pretty surprising what you will uncover.

------
Pistos2
I think anyone heavily involved in a not-too-unknown open source project can
get this experience, via mailing lists, forums, issue trackers, IRC channels.

~~~
marcusbooster
Depends who your target is. The channels you listed require a bit of tech
savvy, my mom is not going to file a bug report.

------
andrewljohnson
I tend to agree, but there are obvious counter examples.

~~~
thinkzig
Such as...?

