You’re absolutely right, davorg! null != ‘null’
Well sure, when I worked in an ER we had people come in all the time unconscious with no ID. They were identified as John or Jane Doe and distinguished from each other by admission time. Unnamed babies are “Baby [Surname],” or “Baby Doe” if the mother is unknown.
Likewise, if someone’s just being difficult and refusing to reveal their name or insisting they don’t have one, they’re John or Jane Doe. (I’d have gone with Rumpelstiltskin just in case, but the bureaucratic mind doesn’t work that way.)
There’s John Doe of X, but that’s a stage name. He might have had it legally changed.
I knew only the first two of my examples and ended in the Finnish Wikipedia for the last two - Ana Horvat is Jane Doe in Croatia, not included in the list you linked
That’s surprising. Car audio software is usually so carefully and thoughtfully engineered. /s
There’s also the situation where you know Rumpelstiltskin is his name, but you’re not sure you want to go back to the responsibilities of motherhood.
One of my favorites:
But ’Null’ is not Null.
Opposite problem where I work. Our MRP system cannot handle short names. Our accountant with a 2-character first and 2-character last name (like Yo Ma) couldn’t create an account; the software insisted on 3 characters minimum for each.
So he just doubled both of them… from then on, we called him YoYo MaMa.
Worse: maximum of 8 characters for the password field, only upper/lower alphabetic plus 0…9, no punctuation at all. Luckily it’s an internal system only…
I’d just want to neck punch the band for that name
I looked that one up on Last.fm and was impressed to see they actually have it listed that way.
Why not an empty string, instead?
I’m not sure what market you are writing from; but at least in the US ‘health information system’ would likely intersect with insurance/billing/medicare/medicaid at some point in the process; and there would likely be hell to pay if somebody’s “simpler variant” doesn’t match the billing info, name associated with SSN, etc. People tend to think you are up to something when there is money on the table and your name starts shifting around.
Are these vendors just hoping that you’ll shut up and sign off, or do they actually think that building a product that munges data is going to work?
I have often asked myself this question. The short answer is that in some systems it is necessary to differentiate between null (absence of data) and the empty string (string of zero length). If you are designing a system from scratch you can obviously make the correct decision; the problem comes when interfacing with badly behaved legacy systems.
I’m going to have to be vague about this for IP reasons, but in one example it was necessary to mine and compare two databases from different vendors that supposedly stored information about the same entities. Unfortunately as with human names the entities do not have a universal prime key. The entities may also move around so they are not always at the same physical (or network) location.
In one software revision an entity might have null at an identifier location. In a subsequent revision it might have an empty string, or even the word NULL. One system might store these as null, “” or NULL; the other might store them as “”, “” and “NULL” and a third might store them as “null”, “” and “NULL”. It becomes important to find out if the systems being compared are tracking software revisions as well as identities.
I suspect colleagues became thoroughly tired of me rampaging around the office screaming "why can’t the morons all agree on a UID and stick to it (expletives removed), but that’s how it was.
I can actually tell you that vendors do exactly that; they produce systems that do not capture data correctly. This does not seem to cause a problem for insurance, which relies on policy numbers almost exclusively. Our public health funding also does not depend on accurate identification of the person receiving the service, just on accurate identification of the service being provided.
I’m writing from Australia, but many of the systems used here have been developed in the US with heavy localisation. Needless to say, the vendors are quite surprised and put out when we make these sort of demands. They fail to understand that the issue is not financial, but accurate identification of people to ensure that medical records are as complete as possible.
They also seem surprised when I (and others) take the line that systems must change to meet the business requirements, not that the business should change to makeup for shortfalls in the software.
These articles are more than a little unfair to programmers, I think. These are lists of misunderstandings that most people have about names, most notably, project managers designing and expecting these systems to be built. Programmers are very infrequently working in a vacuum. A more accurate title might be: “Things that programmers can’t afford to take into account if they’re going to deliver a product to spec on time.” Same applies to “misunderstandings about time.” Reading through the comments here, it’s plain to see that there really is no neat solution. This is something that executive directors and project managers have no patience for, and really don’t like hearing, and will not listen long enough to have explained to them.
Try telling your UI/UX team and boss that this is the way you want to set up your interface. It’s really elegant, and I love it, but from a “if it takes them more than 1.36 seconds to fill out a form, we’ll lose the sale!” perspective, convenience for the majority often takes precedence over creative solutions.
Li’l Bobby Tables is certainly an exception, that’s on the programmer. But for some reason, the western world, not programmers, have decided that you should be able to “search by last name” or format greetings using a single salutation and last name, etc… These expectations exist as part of the world that programmers are programming to.
Now I’m retired I can indulge my fantasies of a nicer and better world.
That isn’t the Western world; it’s the US. Remember that Microsoft’s products didn’t have a proper solution for the accents used in most non-English languages, and the Mac only did because they had a French Canadian in there at one time, as I recall. As TFA notes, early programmers couldn’t even cope with Irish and Scots names. Those early products certainly weren’t the real McCoy, let alone the real O’Brien.