The Problem with Software

While the hardware is less than perfect, it can comparatively easily be understood. We can see the keyboard. We know how big the monitor screen is and how fuzzy it looks. We know how much RAM, disk storage and clock speed we’ve got. These are straightforward constraints.

Software is tougher. Instruction sets that operate a tool can usually only be evaluated by observing how well the tool performs its task. But when the tool messes up, a debate usually breaks out as to whether it’s a software, hardware or operator problem. Usually, of course, it’s a combination, but while the hardware and operator problems can be sorted out quickly, the issue of what exactly the software instructions were telling the tool to do is often a lot harder to get a handle on.

This is where it is useful to think about some of the traits of the people writing those instructions, because computer Special Instructions are generally reflections of the personalities of their authors.

The Hacker Mentality

Many software authors are hackers at heart. They love machine code, they love learning to talk to computers and penetrating to the deepest depths of their little binary hearts. It is a passion for them. The elegance and depth of their virtual communication is a central element in their work. Nothing wrong with this, except that they aren’t particularly interested in people who aren’t passionate about computers, and they haven’t got the time or interest to make their work particularly comprehensible for such folks (meaning, of course, us). So their documentation is generally obtuse, obscure and what us educators call “lacking in perspective,” and their programs tend to be hothouse flowers: they work great on the bench but they often leave a bit to be desired when you try to use ‘em in the real world.

“Whaddya Wanna Do That For?”

Another foible of software authors is egocentricity. There is a tendency to see software in terms of what you want to use it for, and this is true for the authors as well as the customers. One of the primary characteristics of really well-written software is that it permits users to do things that the authors never thought of. More often, though, software hangs up when you try to do something the author wasn’t interested in, even if it is, to you, obvious. A Riddle: How many programmers does it take to change a light bulb? Answer: Five. Four to hold up the car and one to change the tire.”

Hyperbabble

Another characteristic of some software authors is that they get hyper, reflecting the high-speed behavior of the computers they work with. They talk fast, spraying words at an idea or problem. There is a breathless sort of frantic assault, as if the job or question can be overwhelmed by sheer speed and quantity. Such hyperbabble, of course, tends to bury our needs and concerns in hyperdebris.

So, when you download yet another piece of software and agree to the click-through license, you are probably once again encountering the work of a programmer or team that loves computers and their Special Instructions to a point of obsession, who is egocentric to the vanishing point about your subject area and who tries to talk at 1.5 mb/s. These qualities in combination are a little scary (would you like your surgeon, say, to be this way?), and so you pray (if you know enough to consider such a thing) that the publisher has cooler heads standing between the authors’ machine code and your hard disk.

The Publisher’s Point of View

Meanwhile, the publisher has problems too.

Beta-testing and Debugging

Alpha-testing refers to making sure that stuff you’re going to sell works, and it is pretty straightforward. Everybody does it. Beta-testing is the process of making sure that it will work in a broad range of environments and for a broad range of needs (i.e. “The Real World”). Such testing is remarkably expensive, and while you’d think it’d be standard procedure for serious publishers, my sense is that it gets done minimally. This loops back to the “Whaddya Wanna Do That For?” syndrome. If your usage doesn’t conform to the author’s (laid out on a test bench using the author’s favorite operating system, software and music style, f’rinstance), the software may very well simply not work for you.

So Do We Ship With Flaws or Do We Go Broke Doing In-House Beta-Testing?

As I said above, it is expensive to do comprehensive beta testing. It is also impossible to do complete beta-testing. There are always things for which you have not tested, and even if you did, by the time you ship, some things have changed enough that your beta-testing is no longer adequate. So, at the very best, it’s a fine line. You’ve gotta ship stuff you know is less than perfect. How much less than perfect are you willing to accept?

This is usually dictated by (a) how concerned you are about customer complaints, (b) how concerned you are about being sued for mail fraud, and (c) how concerned you are about paying off the accounts payable as opposed to being in business in twelve months. As I said, it’s a fine line . . .

The Salesman’s Dilemma: You Want Me To Tell ‘Em Not To Buy It?

Sales folk have a similar moral problem. They are usually paid as a function of the amount they sell. It is not in their immediate best interest to tell you that the current version of BachBeethovenBrahms®Sequencing Software probably isn’t going to cut it for your rap grooves. The truly professional ones will steer you away from stuff that would waste your money (when you run across such salespersons, treasure them excessively, buy them fine hooch on a regular basis and give them your exclusive business). But until salespersons have conclusively demonstrated such professionalism, you have to assume that they will tell you sweet lies because, well, it is in their job description to do so.