Anyone who's had to explain "sorry, that field only accepts letters and numbers" to a customer whose surname has an accent, or watched a name silently get mangled on a boarding pass, has run into one of the most persistent and least glamorous problems in software: handling names correctly. It sounds like it should be a solved problem, and yet it keeps breaking in the same handful of predictable ways.
The naive assumption that causes most of the trouble
A huge share of name-handling bugs trace back to one quiet assumption baked into a form or database schema early on: that every name has exactly one first name and one last name, both made of plain Latin letters, and that title-casing a name is as simple as capitalizing the first letter of each word. Every part of that assumption is wrong for a meaningful share of real names, and each wrong assumption produces its own specific, recurring bug.
"First name, last name" isn't universal
Plenty of naming conventions don't map cleanly onto a two-field first-name-last-name model. Some cultures place the family name first. Some people have a single name with no separate surname at all. Some names include multiple components that aren't simply "first" and "last" in the Western sense — a patronymic, a clan name, a name that changes based on marital status or generational position. A form that rigidly requires both a first name field and a last name field, both marked mandatory, will either reject a genuinely valid name or force the person to invent a fake value just to get past validation, and that fake value then propagates into every downstream system, occasionally for years.
Naive capitalization breaks a specific, common set of names
A simple algorithm that capitalizes the first letter of every word looks fine until it meets a name like "McDonald," "O'Brien," or "von Hayek." Naive title-casing turns these into "Mcdonald," "O'brien," and "Von Hayek" — each wrong in a way that's immediately obvious to anyone who actually has that name, even though the underlying code passed every test the developer thought to write. The specific fixes aren't exotic: "Mc" and "Mac" prefixes conventionally capitalize the letter immediately following them, names with an internal apostrophe capitalize both segments, and certain lowercase particles (von, van, de, and similar) conventionally stay lowercase in the middle of a name even though every other word gets capitalized.
None of these are edge cases in the "so rare it's not worth handling" sense — collectively, patterns like these cover a meaningful share of real names in any reasonably diverse user base, which is exactly why the bug shows up in production so often despite feeling like a minor detail during development.
Restricting characters to "letters only" quietly excludes real letters
A validation rule written as "letters, spaces, and hyphens only" is usually written with unaccented Latin letters in mind, silently excluding names with diacritical marks, names using non-Latin scripts entirely, or any character the original developer didn't think to test with. This is a genuinely common source of frustration, because the person affected isn't submitting some unusual edge-case input — they're typing their own name exactly as it's spelled, and getting told it's invalid.
Sorting alphabetically has its own quiet assumptions
Even something as apparently mechanical as alphabetizing a list of names carries assumptions. Sorting "by last name" assumes there's an unambiguous last name to sort by, and for names with a compound surname or a naming convention that doesn't match the first-name-last-name model, a script that mechanically grabs "the last word" as the sort key can get it wrong in ways that are individually invisible in testing but collectively significant across a large enough dataset.
Practical takeaways for handling this better
None of this means every system needs to solve name handling perfectly — that's a genuinely deep problem without a universally agreed answer. But a few practical defaults meaningfully reduce the frequency of these bugs: avoid rigidly requiring separate first and last name fields when a single combined "full name" field would work, avoid restricting input to a narrow character set that excludes legitimate letters from other alphabets, and if you do need to auto-capitalize names, build in the handful of well-known exceptions (Mc/Mac prefixes, apostrophe names, lowercase particles) rather than relying on the naive every-word-capitalized approach.
A tool for the specific capitalization problem
If you're cleaning up a list of names that's already been mangled by inconsistent capitalization — imported from an all-caps spreadsheet, or typed by someone with caps lock stuck on — our name capitalization tool specifically handles the Mc/Mac, apostrophe, and lowercase-particle cases described above, rather than applying the naive capitalize-every-word approach that gets those specific patterns wrong.
The broader lesson
Names are one of the clearest examples of a broader pattern in software: an assumption that feels universal to the person who wrote the code is often just a reflection of their own limited experience of names, and the gap between that assumption and reality shows up as a real, if quiet, friction point for a meaningful share of actual users.