Eric Raymond peeved me this morning…

I was on my morning commute to school, reading my ethics textbook, happily processing information about intellectual property and copyright law (my favourite things!) when I read this:

“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…

Getting closer to committing?

So I feel like I am close to having closed up most of the original issues with the patch. After the conversation with Ted I was feeling good about how to wrap the source indexing so that it’s only applied to a Win32 platform.

The newest patch is here and basically the outstanding issue is just the path to the pdbstr binary. What I’m stuck on is that right now I’m passing a path to pdbstr in my build directory but when this patch is committed it will be somewhere else – which may allow for the setting of the path using global variables in the Makefile that I can’t use on my local debug build.

Some sleuthing should clear that up soon. Perhaps 0.6 will be a commit? I’m setting my sights high for that, and then I could spend some time writing a pdbstr replacement in the last few releases.

What’s coming for 0.6

Recently I had a conversation with Ted on IRC about how to take steps to make the patch work properly for Win32 platforms.

Here’s the gist of what I’ll be working on for 0.6:

ted: http://lxr.mozilla.org/mozilla/source/Makefile.in#174
ted: that's where symbolstore.py actually gets run
ted: you see how it uses $(MAKE_SYM_STORE_ARGS) ?
ted: up above that line we define those per-platform
ted: like windows gets -c to copy .pdb files
ted: in the main() function in symbolstore.py, we process the cmdline args
ted: so ideally we'd have another flag there
ted: --generate-source-server, or something

That’s my task for now. Off to play with the Makefile.