Home > Announcements, Articles, Uncategorized > It's My Name – What's in a name?

It's My Name – What's in a name?

June 8th, 2013

Hello everyone, my name is Steve Mekkelsen Madden, or Steven Michael Mekkelsen Madden if you want my full legal name.¬† ūüôā¬† So why am I being formal here of all places?¬† The answer is quite simple actually, I am creating this blog so that I can get all my fellow software engineers comments and opinions on a very real life software problem; the “name” fields and then make a decision to change the world, or at least a standard anyways.

As you can probably surmise, this subject has to do with changing some of our standards and ways we view/think about what we set name type fields to be in our software applications.¬† Are we using a 1970’s, a 21st Century standard or something in between them?¬† I’ve spent a considerable amount of time fighting with organizations to support our name in their¬†business applications, only to be told, sorry Steve, we just don’t have enough spaces for your last name or we can’t put a space in a last name field.¬† This is just one sad story after another and it is now time that “we” set a new Global Software Standard for Names!

User Name Standards Proposal to Association of Software Professionals

Overview:¬†When the computing era began to hit the retail markets and consumers back in the 1970’s, disk space was¬†at a premium cost for each byte/character used.¬† As a result, some field names were set extremely short like AN (account name), or AcctN (account name).¬† There were also restrictions on the number of bytes¬†allocated for the values of these fields and hence a name field could be as short as 15 characters for both the first and last names.

At the time, world travel was still in its infancy and our standards were not compromised.¬† When all the new airlines came in and started offering round trip flights to most parts of the world, this also led the U.S. into a new era of foreigners coming to the U.S. and staying either on VISA’s or as new citizens.¬† So what’s the issue you may ask?¬† Well first, let’s think about what our most common names were at the time.¬† We didn’t have many personal computers in the market place, so we didn’t have to worry about how long names were.¬† But even in the 1970’s, a name like Steve Madden, Tom Jones, Albert Einstein and Bill Cosby would fit in our 15 character values for whatever software may have been available at that time.¬† Unfortunately, other countries citizens names didn’t quite follow our standards because their culture included family names and some on both spouses families which makes for a very long name.

So flash forward to today where personal computers are in almost every household in the U.S. and abroad. Now the standard short 15 character name field becomes a serious limitation to the software.¬† Now let’s consider businesses and what services they have to offer for their customers.¬† There are fields like account_name, customer_name, legal_name, billing_name, mailing_name, etc.¬† There are many fields which¬†attempt to cover what is needed for today’s marketplace.¬† Unfortunately, we still fall short even with the field names and values.¬†¬†With¬†“disk cost” being at its all time low, we still as software developers,¬†restrict the amount of spaces to be used and what is worse, what the default validation on those field values impose.¬† Some software restrict the use of dashes “-” or spaces in a name field value.¬† Well, as you may or may not know, the name field values can contain spaces and dashes in them and are perfectly legal.¬† Did you know that you can go to a court in the U.S. and request a name change to virtually anything you want (within reason, and not to escape debts of any kind)?¬† The judge will speak with you during the name change process and approve or deny the request.¬† This is very common when citizens get married and want to include their¬†name in some way or for other reasons.¬† If our software cannot accommodate these scenarios, then we have failed as software professionals.

An example is the use of my legal name “Steven Michael Mekkelsen Madden”¬† where “Steven” is my first name,¬†“Michael” is my middle name and “Mekkelsen Madden” is my last name(s).¬† My maiden name (name prior to¬†marriage or name change) is “Madden”.¬† When my wife and I married, I added her last name before my last name¬†and she added my last name after hers resulting in SherriLee Mekkelsen Madden.¬† So that gives me 31 characters for my name and 26 for my wife’s.¬† Sounds simple right?¬† Not so!¬† We have issues with State and Local Government Offices, Healthcare Professionals (Insurance, Hospitals, Doctors and Specialists), Utility Companies like Telephone, Cable, Satellite, HVAC’s and as well as Department Stores and Banks who provide a credit/debit/store card of some kind where our names just¬†does not¬†fit.¬† Our youngest daughter also has two middle name¬†“Violet Mary” so when she is asked to provide her middle initial she is¬†not happy when the software only allows one middle initial.

That’s the overview behind this proposal to correct our series of name issues across all markets and once and for all provide an industry standard for “name” fields and values to support organizations and individuals on a Global Scale!¬† This link contains the content of this post “plus”¬†two tables describing each field name, value and validation imposed.¬† Supporting¬†this new standard may require programmatic changes to support increased field widths on a variety of displayed data and/or printed data on forms, pdf files, cards, etc.¬† I am looking for your comments, suggestions and your support.¬† If you support this and agree to make the changes in your software applications (or already do), please add them here and I will make sure they are also posted on my websites.


Announcements, Articles, Uncategorized

  1. June 10th, 2013 at 10:53 | #1

    In my own programs that store addresses, I only support three fields “First”, “Last”, and “Company”. While I limit the length of each field to 80 characters internally, the actual data is null terminated strings so I could easily increase the lengths in the future if I wanted without breaking anything.

    For a name like yours I would simply put “Steven Michael” in the FIRST name field, and “Mekkelsen Madden” in the LAST name field.

    I try to avoid lots of dedicated fields for middle names, Dr/Jr/Sr, etc. as these just waste storage space for the vast majority of people who don’t use them. I can easily add them as part of the first/last names if needed for the few individuals who use them.

    Since addresses almost always print first and last name together, it’s rarely an issue if I split the names into the incorrect fields. It still reads the same when printed out.

  2. June 10th, 2013 at 13:20 | #2

    Hi Anthony, thanks for your post and detailed info on how you work with the name fields. I’m not sure the argument of disk space is an issue here since disk space these days is not an issue because the cost per megabyte is very low. As for the name and how you split them into two, that may work for some scenarios, but not all.

    Take for instance my daughter’s name of Adriane Violet Mary Mekkelsen. Violet Mary is her middle name(s), so your scenario would be invalid and most certainly insult my daughter if she got mail addressed to Ms Mary Mekkelsen. ūüôā

    Another example would be a name such as Mary Beth Elaine Johnson Smith. Where Mary Beth is her first name (yes with a space between them – could have a dash too). Elaine is her middle name and Johnson Smith is her last name(s).

    Now the above are American Names, look at some names from Mexico, India, Japan, China, etc. The names get even more complicated as we look at those since they can introduce more than 1 first, middle and last name.

    So what I’m proposing here is that we not make decisions with names on our own to fit the software fields, but support exactly what we call ourselves. That’s he current problem. As software programmers we control just how fields are used and recommended. It is not correct to tell our customers to just put one middle name in the first and another in the last to get it to work. Instead, provide them with fields to support their customers needs! Anything short of this, we haven’t done our jobs.


  3. June 14th, 2013 at 06:23 | #3

    It reminds me of the issues with “Falsehoods Programmers Believe About Names” at http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

    I think it would be a very powerful thing to have a standard for handling names in software so each developer doesn’t have to reinvent the wheel.

  4. June 14th, 2013 at 11:05 | #4

    I loved the link you referenced! So darn true that we tend to “assume” we know best because we are the programmers! You know what “assume” means right? Anyone who has taken business classes would know to break the word into three parts and you get your answer, “ass”, “u”, “me”. Meaning: If you assume you know best, then you make an “ass” out of “u” and “me”.

    I’m going to post that link, if you don’t mind on my site related to this (http://www.itsmyname.info/links.htm) and (http://www.itsmyname.info/blog/blog5.php) and give it some more exposure again! ūüôā


  5. Mike Newman
    June 18th, 2013 at 12:05 | #5

    Very good proposition and long overdue. We should perhaps consider what we want to use the names for in our software. If it were just identity we could take the whole name just as the person typed it (we probably also need some part of their address too for deduplication in some systems). If we want to address someone in a letter we would want to know which part of the name should go right after “Dear”, as in “Dear Mr Smith”, or if we are going to be familiar, “Dear John”. I wonder how we could make it easy for the poor put-upon form-filling public to identify themselves AND help us to address them politely.

Comments are closed.