To get a feel for how this feels consider the last time you took a car to be fixed and had to talk to the mechanic, or the first time you took clothes to be dry-cleaned. It feels belittling, doesn't it?
Your mechanic example isn't convincing to me (I don't remember ever feeling belittled talking to a mechanic or dry-cleaner). Trying to debug a problem that someone else is having with your code is more like a mechanic trying to fix a car solely by talking to the owner on the phone while the owner, who doesn't know the ins and outs of car maintenance, has the hood open and is holding the only wrench he owns.
Do two things: Comprehend these stories as a description of the impedance mismatch. Design your systems with this data in mind.
To get a feel for how this feels consider the last time you took a car to be fixed and had to talk to the mechanic, or the first time you took clothes to be dry-cleaned. It feels belittling, doesn't it?
Amazing how many people and institutions encounter the mismatch and do nothing about it. It sucks. It sucks = Pain. Pain = opportunity.
I found it amusing, as it has been happening to me lately.
That's a myth IMHO, there is no evidence that this is true.
Besides, I don't think the author claims that "users are stupid", but that they often don't take the time and diligence to make their case as clear as possible, because they lack awareness that the open-source devs are doing them a favor.
Apart from that, I do fear that writing this article probably won't help solving the problem.
I have observed a few devs who are not so good at understanding a different point of view while they are also fairly attention getting. I think this is where the idea comes from. Also, it's pretty hard for a non-dev to understand a dev's POV, which adds to the communications problems.
Let me guess: you have never actually worked in the field, or if you have, it was some trivial job like CSR-1.
It's not about being clever or stupid at all. It's about being inconsiderate or unthoughtful. People of all stripes are guilty of that. Having been on the wrong end of it enough times I try very hard to give just a little thought to the role of the person to whom I'm speaking. When I go to my mechanic, I am the user and I want to make it easy for them to help me.
If it's a reasonable request, I'll try to look at it, otherwise, tough luck unless you want to become a client. If one of my clients came to me and said "I did something and some other thing broke" I wouldn't snap at them, but when it's someone who's getting free support, then it's on them to take part of the responsibility to provide as much information as possible.
Joking aside, the (user) devs should provide as many information as possible per question since back-and-forth communication cause friction which resulted in their problem got resolved slower.
Also the (user) devs should self-reflect, isn't it annoying to receive bug report without adequate information?
Pulling the information you need from users to fix a problem can be quite some work.
This decreases the time available for development. That's all. Hence "DoS".
I don't see any belittling in that.
Oh come on. It's DoS. Pretty please? Not respecting capitalization is definitely a way to DoS a developer...
Pot, kettle, black, etc.
I find the following things quite easy to do: not replying to random emails, ignoring stuff on irc.
Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
http://www.joelonsoftware.com/articles/fog0000000068.html
The entire discussion about the zone is enlightening. If you haven't read it, do so; it'll make you think during your day.
Users communicating directly with developers is a nice idea that sounds good at first, but unfortunately it can't really work when
a) there are many orders of magnitude more users than developers
b) users are not technologically advanced enough to provide the developers with useful (and preferably only useful) information about the bugs
This means that developers are effectively DoS:ed to death when trying to directly support a piece of software with lots of non-tech-geek users. What could solve the problem would be a group of people between developers and users which could translate normal language to and from tech-speak, and evaluate the importance of different bugs. I guess this can be automated to some extent with bug-tracking software, but I don't think it's enough when the software in question has lots and lots of users.
