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: Some developers joined a project with a large codebase which had been up and running for a while. They stumbled upon an aspect that made it harder for them to understand. These new-to-the-project devs proposed a small change:
Why is this named
Dwankie? It keeps tripping us up. Can we rename it toApplicationConfig? It’d be a lot clearer.
The group’s current decision-making process: Is no clear majority dissatisfied? Then keep the status quo.
The long-time devs disagreed with the change. They acknowledged that it would do no harm. But in their view, the code was understandable enough as is. Interestingly, every dev who was unbothered by the odd naming advocated keeping it. They also argued that this wasn’t an important issue. I saw this 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. The change was disallowed.
A better way to decide: Is a significant group dissatisfied? Then we allow change.
Thinking about it, “But is a different group of people ok with things as they are?” is not a good guideline. Instead, 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. 
Dogweather 