Dogweather

It’s a sappy title, but bear with me. I’m wondering if the best lessons of diversity and inclusion can be applied to software development? For example, if something is offensive to others, then it’s worth looking for an alternative — even if I’m not personally offended.

I witnessed an interesting disagreement on a software project: New developers joined a project with a large codebase which had been up and running for a while. But they kept stumbling on quirky internal naming. The new devs proposed small changes like:

Why is this module named Tunngasugitsi? It keeps tripping us up. Can we rename it to ApplicationConfig? It’d be a lot clearer.

Tunngasugitsi is Inuit for “welcome”.

The group’s decision-making process: Keep the status quo unless the majority is bothered.

The long-time devs disagreed with this change. They acknowledged that renaming to ApplicationConfig would do no harm. And yeah, it’d definitely be an accurate name. It’d also be a very low risk change to make, only affecting a few local modules. But in their view, the code was understandable enough as is.

Interestingly, every dev who was unbothered by Tunngasugitsi advocated keeping it. They didn’t see the stumbles of other people as an important issue. I saw their argument boiling down to, “we don’t think it’s a problem”.

This struck me as analogous to “I don’t find it offensive” in the context of inclusion. And so I’m thinking it’d be similarly invalid. Unfortunately, the change was disallowed.

A better way to decide: Is a significant group dissatisfied? Then we allow change.

We should use a rule of thumb based on empathy when deciding whether to act: A sizeable group of people who are dissatisfied with the status quo is enough reason to support change. We shouldn’t require a unanimous or even a majority vote.