Monthly Archive

I’m a technology professional–I’ve even worked for a software company and played a key role in development–so I can say this with some authority: too many developers want to make you think that when their software crashes, it’s your fault. Don’t believe them. They’re human just like you. And, just like you, they’ll pass the buck when they can.

There’s a lot to be said for expertise, for specialization and for technical or esoteric knowledge. I’m a big fan. But these things are also dangerous. When someone reckons himself an expert he starts to believe that, well, he’s better than you. And, in that he’s better than you, if something goes wrong, it’s probably your fault and not his. The understanding of this propensity has applications all over (economics, medicine, religion, music, literature, etc.), but let’s stick to software for now (please do consider those other applications though).

My role in software development began as a wing nut support tech. I say “wing nut” because I liked the stuff other people hated. When folks called complaining that their system kept crashing, I was intrigued. When they phoned us wanting to do things with our software that it wasn’t designed to do, I took it as a challenge. It wasn’t long until I started to do a lot of troubleshooting and testing, which led to the creation of a testing department (of which I was manager) and finally to a programming liaison position.

One of the things that made me good at what I did (and one of the reasons, by the way, that I think it’s boneheaded to let programmers manage and audit themselves) is that I tended to believe the users. I couldn’t help it: I liked them; they were my friends. One of the stupid things my coder buddies (for whom I had the same sort of affection, doggone it) would often ask is “what the heck were they trying to do?”

Now don’t get me wrong, “what was the user doing when the software failed?” is the first question one should ask. But the question my buddies asked was far more rhetorical. What they really meant can be summed up in the old story of the patient and the doctor:

Patient: Doc, it hurts when I move my arm like this.
Doctor: Don’t move your arm like that.

As ignorant as our users could be (and, let’s be honest, often were), what they were doing was their jobs. Specifically, they were trying to do with our software what we claimed it could do.

Without going into painful detail, here’s how it should work: software should have a stated application (hence the metonym). Most software has a specific application. The key is that it should be clearly articulated and well known. Similarly the software’s limits should be identified, expressed and understood. The software should work within its limits and do what its developers claim it can do. The best software will meaningfully and effectively warn you as you approach its limits and, instead of imploding, tell you when you’ve reached them and let you know why your instructions can’t be executed and your data can’t be processed.

It’s simple really. But it’s also hard work. And it requires a bit of honesty and humility–qualities that, sadly, are wanting in most industries and, let’s face it, throughout our culture. Honesty and humility are especially hard to find, I’ve noticed, when the market value of the product is both high and highly subjective, there exists a well-established (though not always well-defined) oligarchy of “experts” and the nature of the industry is in constant flux. Software is clearly such an industry.

You can thank Bill for today’s rant. I’ve been sitting here waiting for Outlook to load. Alas, my mailbox “was not closed properly,” so Outlook is trying to repair it. Notice the subtle insinuation: apparently I did something wrong. And, ever the martyr, Outlook is hard at work fixing my mess.

What I remember is that I clicked that little “X” in the upper right corner like I always do. From what I could tell, the software completed its exit and the data was closed just fine. There were no obvious warnings (certainly no clear ones). No one said, “hey guy, you did something wrong; do this instead.” Not long thereafter, I shut down the computer. Again, no red flags. I didn’t realize I was screwing something up. Silly me.