Even in tech, words matter


This piece discusses harmful terminology in the computer field. The discussion of these terms can be upsetting, so please feel free to stop here.

One of the things you quickly find out as a Computer Science student, is that there's a lot of nasty terminology in the field. Often, that terminology seems not only dated, but it's actively and rigidly enforced. In particular, one that bothers me is "master/slave". When I first started to play around with web sites, I quickly ran into this in the scope of databases. That's odd, I thought, but maybe that's all in the past now and the term can be reused?

Oh, how wrong I was.

This was back when I was in high school. Outside of MySQL, I didn't run into the term's use again until college. There, the term was presented to me as a standard, a convention. I had the privilege to ignore my discomfort and continue with my classes. Then, early in my career I was work working with enterprise middleware, I ran into it again. At the time, I felt I was forced to use the term when doing consulting for clients, although I tried to avoid it as much as possible in any documentation I wrote.

Later, I found myself in the position to write technical education material. Again, master/slave came up. Unlike my consulting days, here I was in the position to dictate what the terminology was. Even if the product documentation didn't use it, the education material could easily mandate a different set of terms. Instead of seeking permission, I implemented my alternative, hoping it would not be rolled back during editing.

Surprisingly, not one complaint was ever uttered about my decision. No one had even noticed.

Often this terminology is applied in tech without thinking. I've even asked some product designers why they chose those terms. After we get past the initial "But that's what it's called!" whining, most stare dumbfounded, surprised that they actually had a choice, but failed to exercise it. 

Why does this mindless application persist?

One of the things I learned in my cultural anthropology classes is that culture is what happens when you're not thinking about it. Some things are "just expected". Unfortunately, in USian culture, that includes no small amount of bigotry. While I was taught that the Civil Rights Era and the racism and prejudice that it struggled against were "all in the past", that past was less than 70 years ago. Not even a century. We still have much to struggle for.

The use of master/slave in technology is one of those unthinking acts of culture. It reflects the bigotry of those that dominated the field when much of the conventions for technology were formed. It's not just a means to describe a relationship, it's a means to enforce a power dynamic that's the blood in the heart of racism. 

Tech has a demographic problem. It's a massively white and male dominated field. Thus far, our feeble attempts to change that have been to hire "diversity consultants" (who are then ignored), teach young women coding (but give them no professional foundation for success), and make occasional donations to other programs to gain sympathy points. It's all rearranging the Titanic's deck chairs, while the real problem is unchecked and unchallenged bias. 

Discontinuing the use of master/slave in code, production documentation, and education materials is...a small thing, it's something that can be accomplished. Once an alternate terminology has been decided upon, it's really only a matter of doing a search-and-replace against the codebase, right?

Most would argue that no, it would simply take too long. It would break too many things. That decision has been made, we're stuck with it now.

I wasn't the only one that thought this was bullshit. I ran across a post on social media where someone decided to put the search and replace method to the test against the Redis source code. Redis is a high-performance key-value store. While it can be used as a database, it is often used as a SQL query cache for Drupal sites. In only a handful of hours, they:

  • Replaced master and slave with alternate terminology.
  • Fixed several places where the term lengths were hard-coded.
  • Updated automated tests for edge cases.

After that, the project's test suite passed. I have little doubt that this would be the same for MySQL, and any other project that relies on such terminology.

"Aha!" you might interject, "but now everyone else's scripts will be broken!" Yes, that's true. Some breakage would occur when changing the terminology, but we in software have a wonderful way of dealing with that: Versions. 

As a software project evolves, often we need to deprecate the use of a configuration key or term in one version, notifying everyone that in the future, use of that will no longer be valid. A future version -- typically a major release -- would enforce the change. Developers and operations personnel would need to update their scripts and do their own search-and-replace. It would be frustrating and cause some hair pulling, but no more than a major upgrade for any piece of software.

In some cases, both sets of terms could be made valid during the deprecation period. We do this so often in software already that I'm forced to conclude the only reason some cling to these terms so stubbornly is that they like them and the unequal power dynamic they foist upon the industry's minority demographics.

If those reasons aren't enough for you, I would also argue that master/slave is also bad vocabulary. The main point of it's continued use isn't to describe a technical relationship, but to enforce an unequal social dynamic. If we were to put that aside for a moment -- noting the enormous privilege one must have to do so -- the term...sucks. It lacks nuance. It's not descriptive at all.

Let's consider a few examples:

  • One active server and one standby.
  • One MySQL write server and several read servers.
  • One application that orchestrates the activity of multiple application replicas.

All of these are referred to as master/slave.

That's three different relationships, all with the same blunt, socially harmful instrument. This is no surprise when you factor in that racism was the intent of it's use, deliberate or not.

Here's a few I like:

  • One active server and one standby = Primary/secondary
  • One MySQL write server and several read servers = Writer/reader
  • One application that orchestrates the activity of multiple application replicas = Coordinator/worker

Each of the above offers an alternative that's short, yet gives additional nuance while dumping the earlier term.

Primary/secondary is easily the most generic of the above examples. Nor is it my creation either. I've seen in in Drupal coding standards as well as terminology from other projects. Primary/secondary can easily be used to replace master/slave. Given the latter's existing bluntness, no meaning is really lost in the change.

I prefer, however, to specify more than one alternative as there's more than one relationship to describe. To me, primary/secondary refers to a specific relationship where there's one active element (the primary), with one or more backup elements (the secondaries). LIkewise, when there's a functional difference between the elements, I prefer to highlight that difference. A common set-up for MySQL is to break up the workload horizontally via multiple machines. Since writes are done less often and must be synchronous, one system is set up as the writer, while all other servers can only read. Writer/reader highlights this difference.

Coordinator/worker is one I came up with while experimenting with Kubernetes (k8s). Here, there is also use of a "master node", which several "worker nodes". While this is slightly better, I prefer to eliminate both halves of the term at once. This discourages a relapse in terminology. Instead of master, I preferred an office metaphor. Manager would work, but both give the sense that they are somehow "above" the work done by everyone else. Instead, I prefer coordinator. The coordinator works with the worker nodes to divide workloads, reschedule them as necessary, collect data, and facilitate communication. 

Changing a few terms in a software project isn't a huge task. Often it can be accomplished in a few hours and we as developers already have existing mechanisms in place to handle disruptive changes. The challenge isn't in the work or the change itself. The challenge is in the will to change.

Contributors and team members may cling desperately to these actively harmful terms. If the changing of terms cannot be mandated without their blessing, it may be time to reconsider their continued involvement in the project. If they are the project, it may be time for you to consider discontinuing use of it, if at all possible. 

Computer Science as a field has long since argued that it's objective and emotionless. None of this is true, as human beings create computer technology, communicate our understanding of it to each other, and we are not objective or emotionless creatures.  Culture, even the most toxic, horrific parts of it, come out when we're not thinking about it.

But we can change it.

This post was created with the support of my wonderful supporters on Patreon.

If you like this post, consider becoming a supporter at:

Thank you!!!