Appropriate values to group user information by gender?

Question

We have an application that stores data regarding a user's gender. The end user does not see this data, only back-end developers.

Possible values for this grouping are as follows:

Female
Male
Other

I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.

She also brought up the following concerns from a data point of view, that someone reviewing the back-end of this application might notice:

• People might think that the numeric values (0 for female, 1 for male) used to store this data in the database are referencing genitalia.
• In binary 0 stands for off and 1 stands for on, meaning there is a possibility that female colleagues and / or programmers might deem this (even more) sexist.
• People might deem referring to them as 'Other' as outright rude and / or offensive.

I don't intend to offend anyone, regardless of their race, religion, gender or sexuality and I've realised that this could potentially offend those who see the way that we're grouping this data by gender, as it may not be inclusive of the gender type they identify with.

In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?

Please note that this was not designed intentionally to offend anyone, it was something we had not put that much thought into while we were designing the database.

Answer 1

As a woman who works on the technical side of development, I really don't care what the underlying numeric primary key value is. I wouldn't have even thought about the connotations that you've raised if you hadn't done so (or course, now I can't unsee it). I really, truly think that someone's overthinking this. Put down however many enumerated values if you so desire for gender. If you want to be truly supportive of diverse gender identities, then three is nowhere near enough :)

However, an even better idea is to ask yourselves, "Do we REALLY need to know the gender of this person? Why? What do we plan to do with it?" If if has absolutely no bearing on how the record is utilised in the system, then it's not really worth collecting.

But to answer your question, it doesn't matter what you use for your database numeric keys. Having genders of just male and female is not sufficient, so if you really want to keep it to a minimal set, you could use "Male, Female, Undisclosed". That way you're not referring to gender diverse people as "Other", and you give everyone the option to choose if they wish to disclose their gender.

Answer 2

These numbers are identifiers in a database. Database record identifiers are, by definition of their purpose, completely meaningless data. Anyone who tries to claim they mean something is almost certainly either not a software engineer or a bad software engineer.

Answer 3

What you should do is nothing.

What you're dealing with is someone who is deliberately trying to be offended. I've dealt with this before over a different issue, where someone actually filed a union action over the colors we used in a spreadsheet. We had to dig in to stop that nonsense, and so do you.

If you change anything, then you are tacitly admitting to doing wrong. Once you do that, life at work will become very difficult for you, because there can always be more reasons invented.

Just as an example, I can make every last number offensive for one reason or another.

• 0 is round and could be offensive to people who are fat.
• 1 could be offensive because someone decides it's a phallic symbol.
• See "South Park" for someone being offended by the number 2
• 3, 6, and 9 could all be offensive to Christians (if they so choose) because of the number of the beast.
• 4 because it resembles a knife
• 7 because it resembles a gun

• 8 because its hour-glass shape promotes a certain body shape.

• ...which leaves five, and if I thought about it long enough I could make that offensive as well.

It may cause you some short-term discomfort, but if you give into one silly demand, there will be no end of it for you. Again, for emphasis. If you change what you have, you are admitting to wrong doing, whether you realize it or not. Once you've got that label slapped on you the next complaint will have more force because you have a "history of bigoted behavior" or some other nonsense.

Stand your ground and dismiss your coworker's concerns as the trouble-making disruption it is.

Answer 4

As it is usually the case in IT, just go standard. Use the ISO/IEC 5218

The four codes specified in ISO/IEC 5218 are:

0 = not known, 1 = male, 2 = female, 9 = not applicable.

The standard specifies that its use may be referred to by the designator "SEX".

Fun note: Even though the ISO explicitely says that no significance is to be placed on the encoding of male as 1 and female as 2, since we are not using the problematic 0, males can say that they are number one while females can say they are twice as good, so that should make everyone happy... right? :)

Answer 5

It's an enumeration of values to allow it to be stored in the database. No developer is going to notice or care that female is represented by 0 and male by 1, and this fact should never be exposed to the end user.

If possible, it might be better to store it in a char(1)... that way you can query it using something like WHERE gender = 'F' rather than WHERE gender = 0. It sorts out your friends issue with it and also provides greater ease of use for future development.

Answer 6

As 2 stands for other (or not sure) people might deem this (somewhat) Transphobic or outright rude and / or offensive.

While the other two points look like someone actively trying to find fault for the sake of finding fault, there's no reason to limit yourself to a tristate with this as the 3rd option. If you want to be more inclusive look at the expansive lists of options sites like Facebook provide beyond male/female and offer the same. Facebook apparently is up to 71 options. I'd provide a direct link; except the only 3rd party sites I can find listing them all have highly negative reactions to the idea.

Answer 7

In summary, the question I'd like answered is the following: Is it appropriate to collect data regarding one's gender using only a select few gender types (Male and Female), and group the rest into an 'Other' category?

That depends on why you are collecting that data in the first place. Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs.

So what exactly is the business need for the gender field?

Do you want to be able to use the correct honorifics and pronouns when communicating with users? Then save the pronouns and honorifics.

Do you need it for some marketing analysis? Then you might indeed have a business case for using a more complicated representation of sex/gender identity, because people with non-standard identities are demographics with non-standard consumer behavior.

Are you building a dating app? Most dating services have a clear binary distinction how the user self-identifies and what partners they are looking for. Dating for people with non-binary gender identity and/or preference is a rather specialized market segment. Ask your management if catering to this segment is part of their business plan. If they do, there are two solutions. Either invent a super-complex system to match people who might be interested in dating each other, or just drop the gender-information altogether and let people decide based on profiles alone.

Is it for reporting to some 3rd party? Then report in the format that 3rd party wants.

Answer 8

Personally, I think your co-worker is overthinking it, as others have already said. Now, more inline with regards to your classification of genders, I have seen some systems user the following five:

Male, Female, Other Specific, Not Known, Not Specified

This number is not a set rule by any means; in fact, for simplicity, I would go with Not Specified for the third and final option.

Answer 9

You have social options and technical options.

Socially, you can just ignore your friend's opinion. She is not on the team and you were just showing her your code and she "went there."

Or, you (and your team) could decide to make a change to (hopefully) avoid the issue. You have a couple of technical options available to you. This assumes your business requirements are not able to be changed with respect to whether and how gender must be tracked.

1. Use strings instead of ordinal values. Of course if you use this field as a key, or frequently in joins, your queries might be a few milliseconds slower, which can add up.

2. Change the ordinal values of your enumeration to be large numbers. The actual value probably doesn't matter. It takes no more CPU effort to compare a large number as it does to compare a small one. If you're using a 32-bit integer, you have 4 billion numbers to pick from. Of course, you should take care that your numbers do not differ by only a 1 or a 0, because we just cannot un-see this post!

Answer 10

I think you are WAY overthinking this.

Whatever you put into the database for the primary key is going to have to have a unique value. Numbers, characters. The computer is a calculator. It deals with numbers.

Accordingly, having unique numeric values implies that each value will have different properties. Some will be less than others. Some will be greater. Some will be primes. Some will not. Some will have one digit, others will have two. We can go on with this ad infinitum, and if we take the OP's approach then it sorta says it's sane for us to mince how the qualities (as described) of these values somehow "ding" the worth of the genders they're associated with in the data.

It's like the old saying of how some people say "tomaTOE", vs "toMAHto". Remarkable, brow-raising?? Slightly. High in value, in the long term? Hmm, probably not. Epic, long-term, cataclysmic effects with the globe spinning off its axis?? SMH.

Answer 11

I was recently showing my friend the project and she pointed out that other people who see this data might deem this sexist, as it doesn't include many identifiable gender types.

That's because your friend is talking about the product, not your technical problem of implementing the product. Your friend is, evidently, of the opinion that your app, website, service, or whatever should be representing gender differently. Your friend probably does not mean to offend your specific job of implementing the 3 options in a database in some way that reflects the decision made by product.

If you have sway in the product, you might consider exercising it. Many businesses have greatly benefited from gender inclusiveness in their product and marketing (source: just watching subway ads reach out to trans people).

If you have 3 gender options you need to implement, then you don't have any social theory problem, just a product you need to implement in the backend, and apply your usual engineering knowledge for naming things with relatively little political implication.

Answer 12

You don't change your application (which may have significant cost for development and testing) unless someone complains who is actually affected, gives a reason that actually justifies the cost, and if your boss tells you to make the change.

The somehow justified complaint that someone who isn't male or female would have to choose a category "other" that makes them somehow stand out can be solved: Change "other" to "unknown, undisclosed, or other". And then you can volunteer to not disclose your gender so nobody needs to be the only person in that category.

And change the question from "which are you" to "which describes you best", so someone who sees themselves 60/40 between two genders can pick the 60% case without having to make a compromise.

Answer 13

First, establish she wasn't joking.

Then, roll your eyes and make it

Other = 0,
Male = 1,
Female = 2

And stop showing her your code!

Answer 14

You are writing a piece of software, and your first and foremost priority is making sure it works and is easy for your peers to work with.

When it comes to data analysis, data isn't inherently bigoted. It's only bigoted when you ascribe further meaning than what is present. For example, if your numbers show that there are more men than women who work at your company, there's nothing wrong with that. If you take that and say that women are therefore less qualified than men to work in your field, that's problematic.

If your friend, or some hypothetical future person, sees that a '0' is being used for women and a '1' is for men, and decides that that number is the number of penises that employee has, that is not reflective of your attitude or your codebase's attitude. Your code is just text, it can't have an opinion.

The question you should ask is, can you rewrite your code in such a way that a programmer not familiar with it can still work effectively? Or will your proposed change trade off clarity/convenience with perceived gender neutrality? If it's the former, then go ahead and make the change if it makes you more comfortable.

An easy workaround is maybe to just replace every '0' or '1' using #define and explicitly name each group, so no one will assume any further meaning behind it.

Answer 15

Why waste storage space by having an Integer variable for this purpose? Use a boolean instead - IsMale: true or false. Null valie if neither male nor female.

Problem solved.