I take it you don't model data for international banks.
Or you work in the USA - the software coming out of the USA is amazingly stupid in its assumptions that every country looks exactly like the USA (just look at the central contact data in SalesForce for an example of US- centric design).
I don't think it's anything specifically about americans but really just a problem with naive people making wrong assumptions and then it's difficult to change things later. Lets say you design a system and assume everyone has first_name and last_name, because everybody you have ever met has a first_name and last_name. Then you design a system with this assumption. You get hundreds or thousands (or more) of clients working on your system, happily entering data, and the somebody comes in and asks you to change it so that it's just one big name field. What are your options? Do you force all your existing customers to change the way they do things? Or do you just leave it and tell the new customer to try to work with things the way they are? I think that maybe some other cultures are less susceptible to this because they may be exposed to more languages and customs early on, but I wouldn't say that this is a solely American problem.
Indonesia is one country where mononyms are common. Which is dumb because the country is so populous, but whatever... (If I was going to fix that country I'd stop the genital mutilation before the database problems.)
If you give a shit about respecting people (e.g. they are your customers), you train your customer service people that if someone has a mononym they enter one name in the screen and the database detects this, confirms that this is what was intended and sets a mononym flag in the backend. If you
Life would be so much easier if we could just look at the source code.
-- Dave Olson
This has never been more obligatory (Score:2, Funny)
Re: (Score:5, Insightful)
Re: (Score:4, Interesting)
Re: (Score:2)
Anyone who says "people have names" is a wrong assumption can be safely dismissed as a crank.
Re: This has never been more obligatory (Score:5, Interesting)
I take it you don't model data for international banks.
Or you work in the USA - the software coming out of the USA is amazingly stupid in its assumptions that every country looks exactly like the USA (just look at the central contact data in SalesForce for an example of US- centric design).
Re: (Score:0, Troll)
Are you a bigoted asshole all the time, or do you just play one on Slashdot?
Re: (Score:0)
Re: This has never been more obligatory (Score:5, Insightful)
I don't think it's anything specifically about americans but really just a problem with naive people making wrong assumptions and then it's difficult to change things later. Lets say you design a system and assume everyone has first_name and last_name, because everybody you have ever met has a first_name and last_name. Then you design a system with this assumption. You get hundreds or thousands (or more) of clients working on your system, happily entering data, and the somebody comes in and asks you to change it so that it's just one big name field. What are your options? Do you force all your existing customers to change the way they do things? Or do you just leave it and tell the new customer to try to work with things the way they are? I think that maybe some other cultures are less susceptible to this because they may be exposed to more languages and customs early on, but I wouldn't say that this is a solely American problem.
You have a process in place (Score:0)
Indonesia is one country where mononyms are common. Which is dumb because the country is so populous, but whatever... (If I was going to fix that country I'd stop the genital mutilation before the database problems.)
If you give a shit about respecting people (e.g. they are your customers), you train your customer service people that if someone has a mononym they enter one name in the screen and the database detects this, confirms that this is what was intended and sets a mononym flag in the backend. If you