# Appropriate values to group user information by gender?

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.

• Edited to bring in-line with the scope of TheWorkplace. Inserted a direct question that asks not for advice on what to do, but whether it was appropriate to group data using only the two types, grouping the rest into an 'other' category (and therefore 'excluding' them as options), which appears to be the OP's main concern. – schizoid04 Mar 2 '17 at 16:18

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.

• Despite what certain movements may have you believe, gender is the single most important differentiator /driver for behaviour. Nothing else even comes close. Of course it's worth collecting. Let's not start restricting system architecture out of a misplaced sense of propriety. I understand where you're coming from but the fact that you even bring up dropping a field so indisputably critical to a database of personal information is a telling sign that this equality nonsense has gone too far. Acknowledging that gender exists doesn't mean that we can't treat people of different genders equally. – Lilienthal Aug 1 '16 at 8:16
• There are plenty of databases that store gender that don't need it. Does it really matter if a meeting planner is female or male? However for certain applications such as medical applications it could be critical . It's up to the business to determine if gender is really needed. I am a woman and a strong feminist, but I would find that interpretation of the numbers as totally ridiculous and off base. – HLGEM Aug 1 '16 at 14:24
• I totally agree with this, although it's one case where, if someone was really making a fuss, I'd just swap the database to use M/F/O rather than 0/1/2. I generally dislike storing strings or characters where an enumeration would do, in case the definition changes, but we're unlikely to change the words "Male" and "Female" anytime soon! – Jon Story Aug 5 '16 at 15:27
• No matter how you encode gender information, it must be represented in the database as some combination of zeros and ones. – Patricia Shanahan Aug 5 '16 at 16:01
• @xDaizu I have no idea if they assign people by genitalia, as I haven't seen the ones of the other guy in the room, nor did I particularly want to. I'm quite certain though, that anyone in the company claiming to be of a less-common gender would get a single room if desired. They certainly would not stick a guy with a girl just because both had a penis. – Erik Mar 3 '17 at 13:06

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.

• To add to that: These numbers aren't even shown to end users. This is literally just an implementation detail of a backend data system. Nobody but the admins will ever see this. For all intents and purposes, it could have been "234239482034023480" for male and "35204238423048203" for female. There is no difference, and assuming that the numbers are sexist because of the order someone chose is ridiculous and absurd. – Magisch Aug 5 '16 at 13:13
• Are you really suggesting that the number for a woman should be higher, and possibly seen as superior, to that of a man? – Steve Ives Aug 5 '16 at 13:58
• I agree with this answer - the questions context is simply absurd. There is and should be no thought on this subject about gender discrimination/bias, it is simply back-end data and should be kept as such. – Sh4d0wsPlyr Aug 5 '16 at 15:23

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.

• Problem solved! Use 5 for Female, 55 for Male and 555 for Other. – Ouroboros Aug 5 '16 at 14:23
• @Ouroboros some are more equal than others. – user37746 Sep 15 '16 at 11:27
• +2 for your whole answer, loved it; but -1 for "do nothing". If any number can be offensive and it doesn't matter, you might as well go standard. :D Seriously, any excuse is good for that... – xDaizu Mar 2 '17 at 16:28
• @xDaizu Great article. Would you mind if I included that in my answer? I'll give you the credit. – Richard U Mar 2 '17 at 21:21
• @RichardU Sure, go ahead ^^ – xDaizu Mar 2 '17 at 22:39

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? :)

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.

• Ah but this would still be sexist, because F still has a lower ASCII value (70) than M (77). It might be safer to use M/W (Man/Woman) because W has a value of (87) :) :) – Jon Story Aug 5 '16 at 15:30
• Using a char(1) could have unforseen knockon effects with regard to collation and character sets, whereas ints will not. – Moo Aug 5 '16 at 16:05
• @Moo Provided the app is designed to handle a char(1) instead of an int, I don't see why it would be an issue. What sort of problem did you have in mind? – Maybe_Factor Aug 8 '16 at 2:01
• @JonStory An M has two peaks, while an W just have one (and, dependent on the font, it's a lower peak). Subtle way you have to remind everyone that there are more men in "top positions", huh? :) :) – xDaizu Mar 2 '17 at 16:30
• Looking at the W, I see three peaks... – gnasher729 Aug 1 '18 at 23:27

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.

• I would add to this that letting users define their own gender and pronouns would be very inclusive. Having lots of defaults is great, but whatever boxes you make, someone won't feel right in them. – Andrew Piliser Aug 5 '16 at 18:04

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.

• +1 "Data models aren't supposed to fulfill political correctness needs, they are supposed to fulfill business needs." – A. I. Breveleri Mar 3 '17 at 23:10

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.

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!

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.

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.

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.

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!

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.

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.

• Some people neither male or female - transgender/intersex for example. Or perhaps they do not wish the company concerted to know there gender – Ed Heal Aug 5 '16 at 12:24
• Androgynous people exist, and there are arguably a lot more then 2 genders. On a technical node, almost all implementations of SQL relational databases use padding so an integer number is likely to be only minimally less space-consuming then a boolean (unless you have a LOT of booleans in that table). And considering its a person database, its likely not large enough for spacing to matter. You could probably make every field in that table a char(500) and it wouldn't matter. – Magisch Aug 5 '16 at 13:05
• @AndrewPiliser all of those can be compressed into 'other' unless you feel OP should update their tables everytime their tumblr page updates as well... – easymoden00b Aug 5 '16 at 18:13
• @easymoden00b I'd recommend letting people write in whatever they want, with defaults for common choices. Also, way to bring up Tumblr. Are you going to call me an SJW next? – Andrew Piliser Aug 5 '16 at 18:33
• And of course if you use a boolean, why isn't it IsFemale? Or better yet? IsOther. – HLGEM Mar 2 '17 at 19:01

## protected by enderlandMar 2 '17 at 21:57

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).