"Anybody who has studied software engineering knows that programmers do not actually spend most of their time originating software. They spend most of their time on service updates and maintenance. Nobody thinks about the implications of this: that the software industry is actually a service industry operating under the delusion that it is a manufacturing industry. Software producers are operating under a manufacturing and cost model, under which the way you make money is building a product and getting it out the door. Because they have this model of themselves as a manufacturing industry, all the bright people go to production and the dumb people go to the support desk. That's why when you call a vendor support line you have to fight your way through three layers of idiots to get down to anyone who knows anything. " - Eric Raymond in an interview.
Well, this got me a little angry.
Now, I won't say that I have never had to do any "idiot filtering" when calling a large company's support services. I blame this on the McJob model of customer service where companies hire people at low wages and then "train" them by giving them scripts to diagnose the simplest problems. Perhaps the company thinks it is also "idiot filtering" for the person who hasn't plugged in their modem and we are all losing with this approach.
This is not exactly what I feel Eric Raymond is saying though. What I read into his statement is that there is a natural filtering of "bright" people and "dumb" people - like natural selection or something and that is just plain wrong.
I'm in the BSD program at Seneca College largely because I would like to be able to better support the hundreds of people I know who need technical support on a semi-regular basis and at the same time be able to help the hundreds of thousands of people I don't know who also need support. I'm interested in technology and have always gravitated towards it while at the same time noticing that others do not. This puts me in a place where I could be a great "bridge" between techies and non-techies.
Why can't programmers and other technically-stimulated people understand that they are a minority? Most people need help to operated systems, use gadgets, understand software and troubleshoot their life-enhancing tech gear. To be someone who supports them does not mean that you are too "dumb" to be on the creative end (which he already acknowledges is a small portion of the industry).
I'm sick of people treating documentation like a hassle, like cops to paperwork, as though it doesn't matter...this leads to poor documentation done for documentation's sake and not for the end user. In my opinion, you have to be "bright" to create tech support documents that help a user continue to patronize your software and not just quit. From what I've learned as a customer service representative in many forms, people will share their bad experiences to approximately 10 times more people than they will share their good ones.
I take this to mean two things for how to go about life:
1. Share your good experiences often to try and make up for how often people share bad ones
2. Be someone's good experience so they have something positive to share
It's a challenge to me and to other programmers to push ourselves to keep things clear and easy to grasp for the lowest common denominator as much as possible. This doesn't mean the software is dumb or low level, nor does it mean that the user is. It means we will agree to speak a certain language together so the most people can benefit. People will clamour for software that does what they need with the least amount of work.
The article is good, I recommend reading it because Eric Raymond obviously knows his stuff and has some great insights to share. I'm inspired by his vision of alternative business models driven by open source. The quote just sparked something that was obviously bugging me already.
Back to reading up on ethics...
2 comments:
"I'm sick of people treating documentation like a hassle, like cops to paperwork, as though it doesn't matter."
But documentation IS a hassle, I would rather start coding something else after I finish a coding project than "document" the project I just finished. (note I am not talking about code commenting which I probably do too much of, I am assuming that you are not talking about commenting either).
I think it's a mistake to tear through coding project after coding project and never take a moment to look at the whole picture, how it operates for someone on a daily basis and to write meaningful documentation that will help people actually *use* your fabulous code.
Post a Comment