In a lot of systems, there are relationships in which one computer, device, or process acts in a supervisory or managerial role with respect to other, similar, devices. Oftentimes, these relationships are said to be a master/slave configuration. My first encounter with this terminology was when, as a kid, I added a second hard drive to the family computer. One drive, the original, was configured as the primary, master drive and the shiny new 1GB drive was configured as the slave.

I hadn’t thought much about the phrase in a long time, until I saw Jacob Kaplan-Moss’s recent series about using Buildbot to run the testing suite for the Django web framework:

We can’t just run a farm of Linux buildslaves running Python 2.6 and SQLite. Since slaves are heterogeneous, the build system needs to be highly targeted. We can’t treat each build slave identically, but we’ll need to target certain types of tests to the slaves that support ‘em.

In Jacob Kaplan-Moss’s case, there’s a computer in charge of a bunch of other (virtual) computers that are running a really staggering volume of tests for the Django project. Slaves isn’t an unexpected term to see here, but the repeated use got to me a little, ultimately leading to this declaration on my notepad: Master/slave has got to go. And you should avoid it in your writing, if you can get away with it.

The most obvious case for avoiding master/slave is that it is offensive because the metaphor diminishes actually slavery. Slavery is a horror involving compulsory labor and sex; to use it to refer to something as benign as a couple of hard drives is a misstep.

But I can imagine voices asking, “Isn’t that just political correctness run amok?” and “We’ve used this phrase forever; why stop now?” so I think it’s only fair to offer a more pragmatic case against the master/slave idiom.

Even if you don’t buy into political correctness per se, it’s still in an author’s best interest to avoid distracting the audience with references totally unrelated to the current topic. While you’re busy explaining a database replication scheme, you can lose your audience to disturbing thoughts about the Atlantic slave trade or the Sudanese Civil War. This becomes increasingly likely as the international character of your audience increases: while the current practice of slavery is almost unheard of in wealthy places like the United States, Canada, and Western Europe, it’s prevalence and broader societal impact is much greater elsewhere, particularly in Africa.

Moreover, the master/slave metaphor is often harder to follow than being specific to your particular system. In Jacob Kaplan-Moss’s article, the master/slave idiom is used to describe the relationship between the Buildbot server (the master) and the various test running machines (the slaves). Rather than obfuscating with the word slaves, it might have been clearer to say testers, test runners, test machines or test VMs. They’re not that much longer to type, but they rely less heavily on context to understand.

To think of a system in terms of master and slaves is fairly common in technology, so I don’t mean to pick on Jacob Kaplan-Moss or anybody else who uses the phrase in their writing and documentation. It’s not deliberately offensive and many of your audience members won’t give it a second thought. But for those that do give it a second thought and for those that are slowed down by the abstraction, it’s a distinct disservice and it should be avoided.