On Diversity Bias in Software Engineering

I dislike the quotes stating, "It has been scientifically proven that diverse teams produce better results" because, to me, it sounds like

a. You don't want to have a diverse team, but hey, money - or -

b. You don't understand how a lack of diversity in software translates into problems in real life.

To me, the reason the teams must be diverse is simple.

1. The purpose of the software is to solve the world's problems (from the lofty goal of improving scientific research to entertaining your toddler while you catch a breath). If your team is not diverse, you may be solving the wrong problems that nobody ever considered a problem in the first place (looking at you. Juicero), while ignoring issues of higher urgency and impact due to not being familiar with them.  

2. The benefactors of software are users. The marketing world is filled with stories about companies trying to conquer the new markets without doing proper research and failing - because the product logo, slogan, or name would be offensive to a different culture. But what about the software products?

In 2012 "Better Off Ted" did an episode ("Racial Insensitivity") where newly installed motion detectors only worked on white people. Of course, that was a comedy sitcom.

To see the real-life occurrence of algorithms not being taught inclusivity, watch this TED Talk by Joy Buolamwini.

3. And this brings us to another reason: not solving the problem correctly, having the solution that is not inclusive, wrong, and potentially dangerous.

Of course, it's not just about problems and users. Careers in technology are incredibly rewarding and can help to even out income inequality and reduce generational poverty. It's our responsibility to make the industry welcoming to all.

We can do that by working on recognizing the bias, be willing to change the language, and reviewing the gatekeeper policies to make sure that nobody is excluded unfairly.

Is it easy to recognize the bias?

A personal anecdote from the perspective of a first-generation immigrant white woman.

I used to work in a company that was very diverse-oriented. They prided themselves on having teams with gender and ethnicity representation, had annual diversity week events, spotlight articles, and continuous training for leadership teams. They were not doing it for the show, and the culture of inclusion was real - never once did I witness an event where a coworker's opinion didn't count just because of who they were.

One day I was participating in security training and could not help noticing that every single study case started with "A Russian hacker did X." There was nothing in the use case that would uniquely benefit from mentioning the hacker nationality; there was no reason to enforce subconscious bias that Russians are sneaky law-breaking white-collar criminals (although also ingenious). And yet I was the only person who noticed this - and the only person in the group of Russian descent.

• You may not notice the bias unless you are a member of the group facing the bias.
• It's not your place to tell another person how they should feel. I wasn't offended by "Russian Hacker," just amused by the contrast between company policy and slides created by the individual, but some people might have been.
• Nobody is taking anything away from you by making others feel more included.

Speaking of taking away - is it time to change the language?

Here are a few terms that I know, used, and never recognized as being questionable until recently:

• Whitelist - a list of approved items with a high level of trust and special privileges
• Blacklist - a list of banned or excluded items with a questionable reputation
  
• Whitebox testing - requires high skilled developers or architects.
• Blackbox testing - does not require knowledge of code, only input and output of a component are verified.
  
• White hat hacker - person finding security vulnerabilities to protect the company.
• Black hat hacker - person finding and exploiting security vulnerabilities for personal gain.
  
• Master/slave communication model - one node assumes total control of other nodes and issues commands.
• Master branch - main branch in the source code repository.
  
• Blackholing - blocking packages coming from a specific domain or IP.
• Dark web - content, sometimes illegal that is hidden from search engines.

Some of these are already being called out and slowly replaced (Drupal, GitHub, and others will follow).

Adjusting the interviewing style

The gatekeeping to software engineering career starts at the interviewing stage.

Giving someone a chance may mean adjusting your style, selection criteria, and beliefs.

If you only hire people who have personal projects that exclude anybody who could not afford a computer, had to work multiple jobs to support the family from a young age, is a single parent.

If you only hire people with bachelor's degrees, that excludes anybody who went to a mediocre or failing school and still was able to graduate and complete community college.  Or someone who didn't have resources available to pay for tuition, or couldn't afford to spend four years not working full time.

If you are rejecting someone for an elusive fit, ask yourself why everybody on your team must be the same and what kind of organization are you really building.