Peter Seebach ([mailto:crankyuser@seebs.plethora.net?cc=&subject=You don't exist. Go away.] crankyuser@seebs.plethora.net)
Freelance writer
2 February 2004
People were mistakenly declared dead long before people had
computers. Frustration results when something or someone tells you
that you don't exist, an experience the cranky user examines in
this month's column.
When I recently received a scam in the mail, I decided to discover how
the scam worked. Unexpectedly, I ran into a problem: When I told the
scammers my name, they didn't believe me. I've experienced that
problem before. A month after I bought my house, a store clerk, while
setting up a department store credit card, told me I had no credit
history. Same story: They didn't believe in my first name, and either
they refused to look it up or their software wouldn't accept my name.
You see, my first name is just the letter A. Not an initial, it's the
whole name, which creates havoc when well-meaning bureaucrats try to
enforce rules such as "full name only, no initials."
Unix traditionally says this with, "You don't exist. Go away" -- an
infamous message that has baffled people for a long time. Perhaps most
disturbingly, it's been copied in modern versions of SSH (Security
Shell), where it's been repunctuated as "You don't exist, go away!"
Either way, the message fails to properly inform users what the
problem is: an attempt to get the password file entry for your numeric
user ID failed. One could easily imagine a more informative error
message such as, "Error: no password entry for uid 367."
In each example above, the problem stems from denial of a person's
existence, even though the person is right there. Although the "You
don't exist..." error message, for its part, at least sticks
tongue-in-cheek, it's still a silly error message, especially in the
old talk program where I first saw it. Wouldn't it seem more
reasonable to first assume the person really does exist, even if she
doesn't quite fit the mold?
The denial-of-existence problem surfaces more frequently with
corporate policy than with software, although, as the aforementioned
examples show, software proves guilty too. However, corporate policy
declares that someone doesn't exist, then simply ignores that person.
As such, policy represents a great way to abdicate responsibility;
time and time again, I'm told that something is a policy with no
person, indeed, no group of people, who can change it. So, where do
policies come from? Do they spring full-grown from the foreheads of
middle managers?
As a favorite example, a major retail chain near me pushes hard to get
personal information; they want a phone number and address before
they'll sell you anything. What, I wonder, do they do for people
without a personal phone number? I assume those people just give a
fake number. Me, I give the chain's customer service number. That way,
those responsible for the policy receive all the telemarketing.
Error checking is a good thing. Likewise, sanity checks represent an
important way to correct likely errors in user-entered data.
Unfortunately, many sanity checks rest upon narrow world views. For
instance, Apple Computer constantly corrects my address on file with
them -- they keep moving me to a nearby city in the same zip code
because 90 percent of my zip code resides in the city a few blocks
north of here. It's not that they've done it once; they change my
address every single time I deal with them. Worse, they do it after my
last chance to interact with the system. So, when I order something
they leave my address correct until I've confirmed my order; then they
change it to the nearby city.
As that example shows, sanity checks should never depend entirely on a
computer without human confirmation. Users should always possess the
option to override the computer. Yes, confirm whether or not someone
really means something, but don't try to outsmart the user too much.
Badly chosen sanity checks can be awful. Phone systems that refuse to
let someone in without a valid number, for example, can be
spectacularly annoying. I once spent more than an hour with a phone
representative while he tried to navigate through a nonworking phone
system. What went wrong? A sanity check caused the phone system to
reject all possible input as erroneous.
A sanity check, moreover, should not check whether or not some data
are reasonable, but whether or not the data are possible. Enough
legally dead people pay taxes these days that you should use a very
permissive notion of possible. Many things reside just outside the
official specs; a system that can't deal with such things is a bad
system. As a specific example, always let users enter dates residing
in the future. You would be amazed at how often that problem comes up.
A friend of mine found a Web site that refuses to load on the Opera
Web browser. Moreover, the site doesn't just look for a browser
claiming to be Opera, it checks for what Opera would say even when
configured to look like (spoof,) a supported browser. After he
discovered how to spoof their browser check, the site worked fine.
So, in that example, the site's designers wrote a special check for
browsers (Opera for my friend) that spoof the browsers they support,
and refuse to display the page for such browsers -- even though the
site works fine regardless. You see such moves often these days, but I
can't say whether it stems from laziness or malice.
Sites that intentionally exclude a small percentage of users are a
little unusual, but not unheard of. Generally, the designers claim
exclusion cuts costs. When you look at the site's pages, however, it's
pretty clear that a page that worked everywhere would have been a lot
cheaper, though maybe not quite as flashy. In many cases, I'd rather
have the easier page; even the supported browser may crash on a badly
designed page.
Such examples show the strange belief that if you design a site to
work exclusively with the most popular browsers and put in extra
effort to keep other people out, somehow those with popular, yet
unsupported, browsers should not visit your site -- as though no
pages work in more than one browser.
It may seem trivial immediately to exclude five percent of the
potential market, but the different excluded groups add up to a
substantial chunk of a market. If your store won't sell to Mac users,
people with third-party browsers, people outside the continental US,
people with JavaScript turned off, people who won't use PayPal, or
people with free e-mail accounts, you're running out of people. Yeah,
a lot of potential customers are left, but how many businesses can
afford to take a 20 or 40 percent cut in sales?
Along those lines, considering that those who don't exist comprise a
big part of the market, granting their existence seems reasonable. As
such, don't play "why can't they just..." with potential customers;
it's frustrating and annoying. Furthermore, the question often
becomes, "Why can't they just spend $2,000 on hardware and software to
work around my mistake?" The obvious answer: they can, but they won't.
This week's action item: Look for funny stories about people who are
legally dead. Do you maintain any databases of people? Would your
company have coped with that problem any better than those in the
stories you found?