Almost all problems with name handling come from two assumptions: 1. Names are identifiers. 2. Names can be used to correlate the same person between two sys

Almost all problems with name handling come from two assumptions: 1. Names are identifiers. 2. Names can be used to correlate the same person between two systems. These assumptions are not universally correct, and so programmers and designers and product managers try to restrict names in order to minimize edge cases and maximize the cases in which their assumptions hold. And these same folks make the same mistakes about names of things as they do about names of people. If a human provides the name, then you are taking on a huge pile of problems using the name as an identifier. Take DNS domain names or AWS S3 bucket names or NetBIOS names in Windows networks or (pick your favorite flat namespace ). The solution? Always use system-assigned (preferably random) identifiers for things that need identification. Think UUIDs. Make the name a descriptive text property of the person/thing that they can change at any time. Consider not having names for humans, but rather just asking the user for the strings that you would like to use in certain places, eg: “When we validate your provided credit card, what is the name that the bank expects?” “What should we put in the ‘name’ spot on packages or letters that we send to you?” “To make this app more friendly, we would like to address you by name. If that is ok, type the name that you would like us to use in this situation:” [ Foo ] Here’s what it will look like: Hello, Foo (No thanks) (OK) Etc etc.