Talk about a word until it makes no sense.  Why would you do this?  This is much of what philosophy seems to consist of, attempting to reach the absolute definition of a word with zero ambiguity.  While a neat intellectual exercise, there exists a threshold where this ceases to be useful for most humans.  Typically most words can be defined in a short phrase.  This suffices to give us a mental picture of what a word is meant to convey.  In fact passing this mental threshold might be somewhat harmful.  There be dragons there. 

We can draw a parallel to programming or to program design.  Consider a database schema or a UML diagram of a painstakingly designed class hierarchy.  Each quantum of information neatly defined in terms of other types, just as a word¹ is defined by other words.  Each word defined to the point of lowest ambiguity.  At least this is the intention of the designer if one follows the typical methodologies for such things.

However, is there a need to leave ambiguity in the system?  Can we equate ambiguity to abstraction?  On some level abstraction and ambiguity are linked. 

Consider the need the most organisms have for ambiguity in their perception of their environment.  Humans do night see all spectrums of light.  We do not hear all frequencies of sound.  The human eye cannot distinguish every possible shade of color.  If you say a restroom is for woman, your brain can picture the type of person that may enter that room.  The general class of woman is sufficient for the needs of blocking males from entering the females restroom.  Our brains have the ability to remove unneeded information so that we can concentrate on what is important.  

This is the crux of the issue.  This is abstraction.  Instead of dealing with the billions of women on the planet, we can deal with the one class of women.  We abstract away the complexity and gain ambiguity.  If we say that all women have long hair, we over specify the general case of women and lose the power of abstraction. 

What information is important in our system and how much do we really have to specify it.  Is it enough that we know that something is a series of characters forming a string?  Is a person’s name a series of fields like prefix, first name, middle name, last name, and another series of suffixes?  Or is it simply one string of characters?  

Let’s examine the first case.  In a large organization there is often a design or architecture team.  This team is typically obligated to define an organizations data.  The team most likely will tend to choose the multi field very explicit representation of a person’s name.  After all, what is there job but to minimize ambiguity and maximize specificity? 

In the second case a lone hacker with a deadline may decide that one long database field is enough to store the name.  This is most expedient and it gets the job done. 

Why does the lone hacker’s system survive longer and cause fewer problems?  Consider the first case again.  Most likely we will have to define a suffix table where every known suffix (Jr, Sr, MD, CPA) is defined.  After all a user must now choose this from a dropdown.  Also the prefix must be entered.  We will need another table to define these.  What happens with a person who has two middle names?  Do we define another column?

It appears that even in the simplest data point definition we have run head first into mushrooming complexity.  How long do you think the design meetings will take JUST to determine how to define a name?  I’ve been in on this and it can take a surprisingly long.

The lone hacker has written most of his system by the time the committee has determine the proper representation of each data point in the system. 

The fact is that ambiguity or rather the ability to handle ambiguity is a feature of a system not a flaw.  Many times the ability to handle ambiguous data from a user or external system saves a monumental amount of redesign and rework.  An example would be a company that decides to open a foreign branch and now must handle names in a different format.  Do we need to redesign our system or does it just work?

A caveat here is the interfacing to other (broken) systems that require the data to be split into small pieces and fed in.  A partners system requires first and last names.  Is this a problem?

It can be.  One solution is to parse the name field.  Ninety percent of the names will probably be first and last name only.  This is because most users are lazy and only want to enter the minimum amount of data.  Some self absorbed types are going to enter every credential in the list including their Boy Scout merit badges.  Now we may have to kick back this data to a human to look and correct.  Last I checked data entry was cheap, programming was expensive.  A great solution?  Maybe, maybe not.  How much money did your design team burn by arguing over what should be in the prefix and suffix table? 

In the age of search, ambiguity becomes more useful.  If we can search on any field in the database than I no longer have to use last name to organize a list of people.  Searching for them may work much better.  Or it may not and you find that you want a separate first and last name field.  

Of course if your requirements call for separate fields because they must be fed to another legacy system, then by all means specify two fields.  You have a valid reason to do so this increases the coherency of the system.   My point is about over specification in the absence of requirements.  

In the absence of requirements, don’t over specify.  Creating unneeded complexity in a system does not benefit anyone.  Ambiguity, as a facet of abstraction, provides the designer a way to deal with complexity or at least to mitigate it.