Falsehoods Programmers Believe About Names (2010) • Hacker News Board

Re: Falsehoods Programmers Believe About Names (2010)

#31

Post by somenomadicguy » Thu, Sep 08, 2016, 9:27 AM UTC

thr0waway1239 wrote: post #9

somenomadicguy wrote: post #7

Earlier quoted context omitted.

One could change #40 to: You need your customers' names. I look at a name the same way I look at a username, more frequently than not it's a hassle you don't need to solve. In many applications a username, or even better, an email address, is the best UUID for a user. We design apps to collect names by default, even when we don't need them and will never use them for any purpose, or at worse, the purpose we use them…

Suppose someone calls in and tells you they want to cancel but forgot which email address they used for signup, what is the next piece of information you ask them?

Sure, that's a reasonable corner case to be concerned with. But, what if you forgot what fake name you gave them? Or what if your name is John Smith and so are 50,000 others in their database?

While designing or refactoring an app, ask yourself, "Do I really need her name or address? Will I risk their privacy and security if my database is compromised? What will I do with this information? Will I sell it to advertisers, or will I ignore it? Will I alienate any potential customers by following the first-name last-name standard?

Really, this has me thinking, WHY do we have a last name? It's basically nationalism for families. "I am Eric, the son of John Smith!" .. So what? Who cares what your family's name was? Think about it. The only time anybody has ever addressed me with my full-name it was in a government context. Are two names really required for a UUID? Why only two? Why not four?

Re: Falsehoods Programmers Believe About Names (2010)

#32

Post by thr0waway1239 » Thu, Sep 08, 2016, 9:30 AM UTC

K0nserv wrote: post #27

thr0waway1239 wrote: post #15

Earlier quoted context omitted.

I hope you are not downvoted. In economics, people talk about the problem of 'sorting and labeling' and how that is an unconscious reaction (which does unfortunately lead to bias) but it helps immensely in the overall productivity of an entire system. When people expect you to design special systems which increases the overall entropy, I wonder if they realize that you too incur a cost for creating that system. I say…

If the argument is economics and system complexity you should favour a single name field over first and last name though. It's one of those rare occurrences where something is both simpler and the better option.

But is it the better option? Suppose x% of the human population has a name which can be reasonably decomposed into first and last names. I honestly don't know what x is, but say it is about 90%.

When you store it as a single string, which order will you choose? Will you have delimiters between them? Would they still be in effect when the person's name has more than 2 parts? If you are ever in a situation where you need to sort by name, will you do it by first or last name? What if there is a need for the other option to the one you chose? Can you reasonably guarantee that you can identify family members if you ever need to? When the customer tells their name over the phone, will it slow down your customer service people if you display the entire name in a way which they are not usually familiar with?

Re: Falsehoods Programmers Believe About Names (2010)

#33

Post by somenomadicguy » Thu, Sep 08, 2016, 9:31 AM UTC

thr0waway1239 wrote: post #13

majewsky wrote: post #11

Earlier quoted context omitted.

The easiest solution is to have their address on file, and send them an actual letter to confirm the cancellation.

And if there are multiple tenants (e.g. roommates), who will it be addressed to? Just wondering if the issue is as simple as leaving the entire name field as a nullable string.

I have a very, very generic name. I lived in a hacker warehouse a lifetime ago where there were 3 of us with the same exact name, so yeah, the address part alone isn't that important.I always make up a fake address, often a police station or a garbage dump, and treat that address as a throwaway.

Re: Falsehoods Programmers Believe About Names (2010)

#34

Post by somenomadicguy » Thu, Sep 08, 2016, 9:36 AM UTC

cronopios wrote: post #23

dirktheman wrote: post #6

I have a friend who's a refugee from Afghanistan. Apparently they don't use surnames there (or at least his tribe doesn't). When he applied for a visa my city council shifted his first name to his last name and he had to come up with a first name on the spot. His name is officially Peter Abdullah now.

At my uni there is a student (from India, IIRC) that doesn't have any surname. Some of our software didn't like that, so we checked her passport, and sure enough, her full name was merely her first name.

Oh man, I really feel for her. Dealing with the various immigration agencies must have been a nightmare. I bet they ended up officially changing her name to "Firstname Firstname", which is what we tend to do in the states..

This bugs me, because if a name is supposed to be a unique identifier, then part of it's existence is to feed the ego. "This is ME! I am Jean Valjean!"

When you then you change somebody's name to fit your short-sighted database constraints you're pretty much saying, "You don't matter as much as our programmers' decisions matter, now move along 9430"

Re: Falsehoods Programmers Believe About Names (2010)

#35

Post by somenomadicguy » Thu, Sep 08, 2016, 9:42 AM UTC

TorKlingberg wrote: post #28

jbb555 wrote: post #12

Ugh this again. No. People have a first name, and they have a last name. Each name consists of a reasonable number of ascii characters. If they decide they are special and don't wish to conform to this scheme how is this my problem? What if I decide my "name" is the first billion digits of PI? Are you going to add that to the list of names that you need to support? No?

The list goes to far and makes people overreact like you with some kind of "Screw this! Get a normal name or get lost!". That is the wrong way to handle this. You don't have to support everything in the list. If your product is only for people in America you can expect them to have a name written in latin letters. You can ask them for a surname and a given name, and they will be able to fill it in, but may be slightl…

I'm curious why should you expect them to have a two-word name written in latin letters? You are the most diverse country in the world, every language, nationality and tribe is represented there.

At least in the states, legal regulations on names vary from place to place. In the state of Texas, if you're a lawyer, you are legally required to tell people this, most commonly done by adding the Esq abbreviation for Esquire at the end of your name. I have a friend who's official name (of course I've obfuscated this) is "Dr. Firstname b. Lastname PhD, Esq.".

Re: Falsehoods Programmers Believe About Names (2010)

#36

Post by Hinrik » Thu, Sep 08, 2016, 9:47 AM UTC

odabaxok wrote: post #16

Similar lists: Falsehoods programmers believe about addresses: https://www.mjt.me.uk/posts/falsehoods-programmers-believe-a... Falsehoods programmers believe about time: http://infiniteundo.com/post/25326999628/falsehoods-programm...

Falsehoods programmers believe about prices: https://gist.github.com/rgs/6509585

Re: Falsehoods Programmers Believe About Names (2010)

#37

Post by K0nserv » Thu, Sep 08, 2016, 9:54 AM UTC

thr0waway1239 wrote: post #32

K0nserv wrote: post #27

Earlier quoted context omitted.

If the argument is economics and system complexity you should favour a single name field over first and last name though. It's one of those rare occurrences where something is both simpler and the better option.

But is it the better option? Suppose x% of the human population has a name which can be reasonably decomposed into first and last names. I honestly don't know what x is, but say it is about 90%. When you store it as a single string, which order will you choose? Will you have delimiters between them? Would they still be in effect when the person's name has more than 2 parts? If you are ever in a situation where you ne…

1. There is no order, just use whatever the user entered. In general don't get smart with this data just treat it as a single blob of text.

2. Sort by the whole thing

3. No you can't guarantee identifying family members any more than with a first name last name system. If you need that it should be an additional part of the system. Presumably for the 90% of people who does have a typical first name, last name combo you can still identify family members in the same way.

4. Just introduce free text search for this field if you need to find people.

Re: Falsehoods Programmers Believe About Names (2010)

#38

Post by thr0waway1239 » Thu, Sep 08, 2016, 9:58 AM UTC

vidarh wrote: post #26

thr0waway1239 wrote: post #13

Earlier quoted context omitted.

And if there are multiple tenants (e.g. roommates), who will it be addressed to? Just wondering if the issue is as simple as leaving the entire name field as a nullable string.

Your address entry needs to be flexible enough to accommodate pretty much arbitrary text. There are no universally required fields for addresses. Zip/postal codes are almost universal, but not entirely. E.g. "name; town; country" is sufficient some places; "name; postcode + town; country" is very common, but it can also go to the opposite extreme of a ridiculous number of separate items, so it's best to just give a n…

I agree with everything you are saying, but you ended your comment with "what should we call you in context X?". "What should we call you in context X" is, at least in the context of the current discussion, the same as a non-nullable string for the name field. Or am I misunderstanding your comment?

To add to my previous comment, what if two or more people from the same address are signed up for your service? How would you help them distinguish between the correspondence each one gets from your company?

Re: Falsehoods Programmers Believe About Names (2010)

#39

Post by Arnt » Thu, Sep 08, 2016, 9:59 AM UTC

TorKlingberg wrote: post #28

jbb555 wrote: post #12

Ugh this again. No. People have a first name, and they have a last name. Each name consists of a reasonable number of ascii characters. If they decide they are special and don't wish to conform to this scheme how is this my problem? What if I decide my "name" is the first billion digits of PI? Are you going to add that to the list of names that you need to support? No?

The list goes to far and makes people overreact like you with some kind of "Screw this! Get a normal name or get lost!". That is the wrong way to handle this. You don't have to support everything in the list. If your product is only for people in America you can expect them to have a name written in latin letters. You can ask them for a surname and a given name, and they will be able to fill it in, but may be slightl…

One of the old classics, I think it was Plauger's book on POSIX, dealt with this in the l10n chapter. One of the examples was "the only customer for this software is the US government, so it only needs English" leading to "then they discovered that the US goverment includes that of Puerto Rico".

How many latin letters are there anyway, 26? 600? I read the latter number in an essay on what typesetters used to keep. Is ' an English letter, as in O'Malley?

Re: Falsehoods Programmers Believe About Names (2010)

#40

Post by thr0waway1239 » Thu, Sep 08, 2016, 10:08 AM UTC

K0nserv wrote: post #37

thr0waway1239 wrote: post #32

Earlier quoted context omitted.

But is it the better option? Suppose x% of the human population has a name which can be reasonably decomposed into first and last names. I honestly don't know what x is, but say it is about 90%. When you store it as a single string, which order will you choose? Will you have delimiters between them? Would they still be in effect when the person's name has more than 2 parts? If you are ever in a situation where you ne…

1. There is no order, just use whatever the user entered. In general don't get smart with this data just treat it as a single blob of text. 2. Sort by the whole thing 3. No you can't guarantee identifying family members any more than with a first name last name system. If you need that it should be an additional part of the system. Presumably for the 90% of people who does have a typical first name, last name combo y…

I realized that I am in agreement on point number 1 - don't get smart with this data, in which case the other points are not very relevant.

But suppose you are working at a place where people are keen on getting 'smart with the data', your replies do increase the entropy if only to the extent that 'we have this idiot programmer who thinks he is too smart to use first and last names as we have always done and is breaking all our reporting systems and is causing hell for our customer service agents'.

:-)