For years I’ve subscribed to standard naming conventions in software development, like master/slave and blacklist/whitelist, until now.
We’re rethinking the language we use for software development
Naming is a big part of software development. We use it to organize and understand a codebase and to identify how objects communicate with one another. This means any language we choose needs to be deliberate. Naming shapes our understanding of how software and hardware work, and like language, it influences our perception of the world.
Racist and patriarchal language is scattered throughout the software and information technology fields. The examples above — master/slave and blacklist/whitelist — are just a few common software terms that reference or imply social structures.
We have a choice. We can maintain the status quo by choosing language that’s obtuse or lead the movement that uses inclusive language. Ruby on Rails made the change earlier this year and other open source communities, like Python, have followed.
In an industry in which there is poor racial and gender representation, it has been eye-opening to see the reactions to this movement: There is resistance and a lot of color blindness among us. People are defending the original intent of these terms rather than considering their impact. It’s not hard to see that associating positive things with “white” (like whitelisted) and negative things with “black” (like blacklisted) is, at worst, deeply offensive and at best entirely unnecessary. So let’s change it.
Why we’re doing it
Creating an inclusive workplace is important to us at Clockwork.
In a world where we’re building artificial intelligence, this movement is essential. Computers are inherently dumb. Even the most well-intentioned machine learning algorithm, like Amazon’s recruiting tool, is meaningless if the people building it haven’t adopted values of inclusivity and practice it every day.
How we did it
Our operations engineers recently led our internal project to find and replace spurned words in our infrastructure. We replaced master/slave in our Icinga monitoring system with primary/replica. We updated documentation for our outbound email server from blacklist/whitelist to denylist/allowlist. Overall, the changes for what we could control took a minimal amount of time.
When we kicked-off the project, the team welcomed the linguistic changes. It was clear that being a values-driven organization helped universal buy-in. As we worked through the requirements of the project, it felt like we were simply breaking the habit of using spurned words and phrases.
We use the principle of inclusivity to guide the work. After the kick-off, the language we agreed to be changed was phased out of our written communications almost immediately. Changing verbal habits was a bit harder, but within weeks, we were correcting ourselves immediately after using spurned words.
A challenging part of the project was determining scope. In technology, we often talk about building on the shoulders of giants. What do you do when those giants use language that doesn’t fit your company culture and values?
A guideline we set for ourselves was to update our documentation (something fully under our control) with our preferred language. We will continue using inherited language when technically required (e.g. documenting specific commands or labels used in upstream tooling). We did this all with the caveat that we will also submit feedback to the companies that maintain those tools. We will share our changes and encourage them to consider similar changes. It may feel like a small thing, but if everyone who felt this way submitted similar feedback, it’s likely we’d see some changes.
We’ve enjoyed the challenge to think about the language we choose for our discipline. Not only in terms of the word choice but also style. Being inclusive means we don’t write in tech speak or use language that most people can’t understand. On a broader leave, this project also made me challenge more terms that have become normalized like the ones above. I’ve recently made the change to use people over resource, folks over guys, and partner over wife.
When you hear the saying that in computer science that there are only two hard things: cache invalidation and naming things. It’s the truth.
