> Handling every “falsehood” gracefully yields a combinatoric explosion in the complexity of your data model. Sometimes this only happens if you started off wi

> Handling every “falsehood” gracefully yields a combinatoric explosion in the complexity of your data model. Sometimes this only happens if you started off with a model that made too many assumptions in the first place. For instance, regarding the "Falsehoods programmers believe about names" list, a naïve American programmer might just go with a simple pair of fields for the first and last name, running into many of those falsehoods, and if they stick with that approach, they'll have a mountain of edge cases to (potentially) handle on their hands. However, if you instead loosen up the format and just provide a single field asking something like "What name would you prefer we use when referring to you?", you avoid almost all of the "edge cases" in that list (many are so widespread that they can hardly be called edge cases) and will end up with an implementation that is even simpler than the one the hypothetical naïve programmer would have provided. Of course, this might cause some difficulty if you need to interact with external systems that require a specific format for a name, but at that point the issue is that someone else has made similar assumptions, not an inherent difficulty associated with using a less constrained format.