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, one important idea is, if some expression or practice 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: A group of developers joined a project with a large codebase which had been up and running for a while. They brought up an aspect of the code which 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 to
ApplicationConfig? It’d be a lot clearer.
The group’s decision-making process: No clear majority is dissatisfied? Then we keep the status quo.
The long-time devs disagreed with making 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: A significant group is dissatisfied? Then we allow change.
Thinking about it, “Is a different group of people ok with things?” 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.