It’s pretty common for me to see someone on Facebook, or wherever, complaining that this or that suddenly stopped working. Or reverted back to an older setting or version, or doesn’t work as advertised at all, even though they looked it up in the help. It’s pretty frustrating for them, because they don’t see how that could be. “It’s supposed to work! What idiot designed this?” Some of the reactions seem to personalize it, as if someone is deliberately messing with them; others are just woe-is-me of some sort.

I’m patient with it unless/until they try to get me to ‘fix it’ for them, or more or less demand that I (who used to work with computers, thus I must know All Things Technical) take personal responsibility for it. That tripped your BS meter, unless you have ever worked at supporting computer users. They usually want someone to bitch at for their frustration, and the helper/tech will do. Somehow, it’s the helper’s fault that someone else created a flawed thing. This is why a lot of people who could perhaps help you, choose not to. They’ve been through that too many times. Those who have not yet learned, or for whom the validation of successful problem-solving is too alluring to resist, keep volunteering assistance.

The words I hated most, and that immediately marked a user as not grasping the situation, were “I don’t see why you don’t just FIX it.” If that were feasible, lady, and if it were that easy, I would. Your great-nephew would–he’d just overwrite everything you have, break everything you want to use by doing an easy reinstall, and then vanish when it came time to help you get your “e-mail working with your printer, and your software downloading in your drive, and your Works chart colors back the way you want them again.” Or whatever other way in which you imagined that solving computer problems was exactly the same as car repair. (That quoted list of complaints was a fairly typical sample. Most people don’t know what the tech terms actually mean, so they misuse them to try and sound more technical, which makes them in fact sound pretty dumb. Kind of like the non-Spanish speaker who responds to Spanish by saying ‘El grande pantaloons’ or ‘buenos nachos.’)

So I’m going to present some generalized realities that a lot of people don’t grasp. Words of ultimate futility: “But it shouldn’t be this way!” Many things should be and are not, or should not be and are. I don’t care how it should be, because I don’t deal in ‘should.’ I deal in ‘will’ and ‘won’t,’ and ‘can’ or ‘can’t.’ I can, however, tell you how it is. You’d be less annoyed if you knew. Or you might be more annoyed–but at least you’d be less mystified. It isn’t always just you. Sometimes, the situation is just unpleasant. It might help to know, at the very least, that it’s not always your fault.

1) Any large, complex piece of software, be it Facebook, your new Massive Ultracarnage III game, or MS Word, always has major imperfections. There are ways in which the documentation is simply wrong. There are features that are broken from day one. The help file cannot possibly keep up with the reality; no one’s willing to pay that many tech writers.

2) Most major ‘upgrades’ are net backward movements, adding some features but mostly moving the same stuff around so you have to look for it all again. It’s not your imagination. You’re not crazy. That’s reality.

3) Most major changes are a series of additional pieces bolted on, rather than rethinking the whole base concept. Thus, most highly mature software is like a passenger car that was evolved from a tricycle, and deep down inside it, still has that tricycle, which is no longer needed functionally, but it’s too much headache to remove, plus removing it would break everything else, thus the whole thing would have to be rethought and re-engineered as a car from the start. They won’t do that very often.

4) If software is online, such as a website, and is very popular, its information and code are stored across large amounts of computers and storage, with some redundancy and ability to share the load if one of them has a problem. This means that your reality will not always be the reality of everyone else. “It’s working fine for me, sorry.” That’s usually temporary, as they are gradually fixing something, upgrading something, or propagating some change about the system.

5) Sometimes, when something on a website is messed up, or an ‘upgrade’ turns out to be broken, or data is trashed, the easy fix is to revert to a fallback copy known to be good. This means that changes in the meantime were lost. It might be many or might be few, depending on how many people used that and how long it took to realize that the new Doodad had a memory leak that threatened some dire consequence.

6) Information systems management is a lot like generaling a battle. You make some hard decisions on the fly based on the best information you have at the time, and you try to avoid heavy casualties, but stuff happens. Expecting everything to go right most of the time flies in the face of this reality. It’s rather a miracle any of it goes right, ever, for any sort of bearable price.

7) All changes are beta-tested on live users. You are the guinea pig. “Why don’t they test it beforehand?” They do, but what they consider beta-testing is not comprehensive because no one can think of ways to creatively break software like several million people. They don’t have several million in-house testers and can’t get them. The only real way to find what’s truly messed up is to give it to the public and let said public work its magic by diversity of use.

In theory, beta-testing should mean ironing out the major kinks before inflicting change on users. In reality, users are the beta testers. They hand you the car and let you do with it what you want. Some people will drive normally. Some will drag race. Some will repeatedly slam on the brakes to see how long it takes for them to fail. Some will set up ramps and attempt stunt jumps. Some will refuse to drive it over 10 mph. Some will wrap it around the first tree they see. Some will put it on a grease rack and start altering it. What is sure: if there is a flaw, someone will turn it up, either by accident or by using the car in a way it was never intended. Software works like this.

A few years back, I remember, there was a WWII operational game that inventoried each unit down to number of operational vehicles and weapons. Amazingly detailed, and players could create their own scenarios to simulate nearly any battle. There was an enormous argument when someone set up a company of trucks and pitted it against a unit consisting of one Tiger tank (which, in reality, could have taken out twelve trucks without even firing its main gun; just run them over or machinegun them). The trucks always won. You can’t imagine the bitchfight that followed, with people screaming how unrealistic the game was. Never mind that the objective of the game was to simulate divisions and corps moving against each other; this microexample ‘proved’ the game was not realistic. Here’s what’s unrealistic: any competent officer or sergeant–hell, a private–attacking a heavy tank with a bunch of trucks in the first place. The developer (Norm Koger, an exceptionally capable fellow) used the term ‘pathologically strange scenarios,’ and he was right. But the point: someone was going to try that, and claim it to be a Major Issue.

8) In information systems management, sometimes so much goes wrong at once that–like medical staff after a catastrophe–the technical people must prioritize. It’s not that your issue doesn’t deserve fixing. It’s that there may well be five more major issues that you don’t know about, that affect hundreds of thousands of users, whereas yours only seems to affect a few thousand. They will triage the eternal process by number of users impacted, severity, and so on. This means there are numerous small problems that will simply never be fixed because they will never be important enough. Repair and testing resources are finite. If you have one of the small problems, you may just be screwed. Since there is always someone with at least a broken leg or a severed artery, your nagging hamstring pull may not get any attention; you may just have to work around it as best you can. Sucks when that happens.

9) Why are nearly all upgrades actually downgrades, or unimportant lateral movement at the very best, as described in 2)? Because you, the user, really aren’t the priority. You never have been. You are dealing with the programmer mentality, which prefers to create the new rather than fix the old. The programmer mentality is abysmal at designing user interfaces–which are the way users interact with the system–because the programmer doesn’t care that much how many steps the path requires, simply that the path eventually leads there. Watch the way a Facebook game devolves and you’ll have an example. It will keep bolting on more and more stuff, in this case to generate revenue, and because programmers like to keep creating the new, but hate going back to rebuild the old. What if most users like it the way it is and don’t want any changes (they haven’t even adjusted fully to the last batch)? Not the programmers’ problem, because the users aren’t what drives the thinking. They can never come out and say that, of course; it’s a shibboleth.

If programmers went back and made everything work correctly, really did it right, they’d get bored. They don’t like doing that. Programming involves more artistry and creativity than most people imagine; creators gotta create. Perhaps more importantly, if they didn’t keep coming up with new stuff they imagined would improve the system, there’d be less need for programmers, with all problems fixed and nothing new planned. Programmers like to have jobs too, even if their job is in fact to make your experience worse. It’s their mortgage payment vs. your happiness; the former wins.

10) Ideal software on a large scale is problematic to create, even starting fresh. In theory, developers would come up with a concept, build it, test it, find all the major flaws, release it, learn about a few that slipped through the cracks, fix those and be done, and move on to re-imagining the next major version. It’s never like that. That takes a long time, and with nothing new being released, there is less new revenue. At some point, everyone who wants it has bought it or pirated it. What happens is that developers wing it a lot faster, and let the world find the flaws, which take longer to fix–and which delay starting on something new.

11) Thousands and millions of users all have computers that differ as much as one human from another. A few humans can’t stand cilantro, for example; it tastes like soap to them. The rest of us can’t taste the soapy stuff, and we keep dunking our chips in the salsa. There is probably someone mortally allergic to kumquats, will go into convulsions if they even touch one. Some people are allergic to everything. We vary.

Even if the hardware were all the same, a different mix of software is loaded on each, and most software does something to the operating system when installed. This means it is inevitable that some user will have some deadly combination of hardware and software, duplicated in only a few cases, that happens to mess with the one piece a given system must have. There is no practical way to troubleshoot or fix that, unless it’s widespread enough to trace to a single item (usually a specific piece of hardware, like a video card, or perhaps even a specific version of that hardware’s accompanying software drivers). Why do the tech people always ask you for a full list of what hardware you have? This is why.

For example: I bought one of the Diablo games. Everyone else loved the new game and said it was brilliant. It hard locked my machine after a few minutes. If this were very widespread, everyone else wouldn’t have loved the game. It probably had to do with some video or sound driver, which I could have upgraded and hoped for the best. Or I could just decide it wasn’t that important, which is what happened. Same with one of the SimCity games: about ten minutes in, just as it was getting interesting, it crashed. Not for most people, who thought it was the best version ever. When you’re in that situation, if you’re in a small minority, don’t count on a solution. It rarely comes.

12) A fresh restart solves a lot of problems, often enough to always do it. Clear the cache, power cycle the modem, reboot the machine, then immediately try what isn’t working and see if it fails again. This is why techs always have you do this: it solves enough problems that it’s nearly always worth a shot. No failure is diagnostic unless it can be reliably repeated from a fresh start, because some failures are a result of an extended, deteriorating operating system session which something else caused to begin deteriorating.

If you can start fresh twice and get the same failure, reliably, you can reproduce it. If you really want it fixed, being able to reproduce it on command gives the propellerheads something to work with–because there is, then, a way to know when it is addressed. Magic words to tech support: “I can reproduce the failure every time from a complete fresh start.” They can sink their teeth into that.

So, you have problems. You always will, here and there. Using a computer is like driving down a highway that has some frost heaves and potholes. Some you will miss, either because you never drove that stretch of road, or because of your alertness. Some you’ll hit. Some will flat a tire or crack an axle. The people who make the software are mainly concerned that most people eventually get there, even if they have to take detours. This may mean that some roads just keep deteriorating, because they are less traveled, and because it was more important to fix a major bridge that was about to fall into a river.

You can still be annoyed about this if it helps you, but the annoyance isn’t going to change reality. But maybe if you at least understand why it’s this way, you’ll be able to guess whether the problem is worth trying to report or troubleshoot, or whether you’re better off just living with it, working around it, or rethinking how important it is to you. Expecting perfect computing is like expecting a perfect round of golf every time, something not even tour pros achieve. Their success is mainly judged by how few major mistakes they make, and that is also true of computing–for developers as much as users.