Is it Time to Formally Represent Diversity in Development ?
Software drives our entire lives now. The most Luddite in our society escape organising their own lives with software but they are still defined and handled by others using millions of apps on millions of platforms by other people and businesses. Most of the time for most of the people it’s unremarkable, but sometimes it doesn’t work right.
Sometimes when it doesn't work right, it inadvertently or negligently makes inferences about people’s identity, humanity, and other things they or others use to handle concepts like worth.
That escalated quickly. Let me back up a step.
Software in the whole is made by large groups of people who have different roles to play in its production. There’s exemptions of course, there’s probably several apps on your phone made by a small group of people or even an individual who made all the decisions from the base concept through to the finished product, but by and large software is made by groups.
Saying that software is the product of programmers or developers is like saying a movie is the product of actors. It’s true after a fashion, but we’re all familiar with how many people make a movie if only by virtue of how many people’s name fling by at the end of one during the credits. Software is largely the same in that lots of people collaborate to produce the end product, but in most circumstances the effort and effect burden is reversed. Everyone in a movie supports the actors who do much of the creative interpretation and all of the display. In software engineering, the programmers and developers are the implementation of other people’s understanding of a problem and the solution for it, translating it from English (*mumble*) into computer speak.
This means that the person who instructs the computer to do something, rarely if ever decides what the computer should do. Other people — often heaps of them — decide what is a problem, what the solution is, and the internal rules that should govern how the software behaves when somebody uses it to make sure that happens.
Let’s see how it can go wrong.
In 2012 Optus came under fire because it appeared that an app for administering their rewards or customer loyalty program insisted that the title “Doctor” didn’t match the gender “Female.” The story ran around a bit and Optus wheeled out the mandatory public relations spokesperson who had investigated and insisted it was OK because the glitch was actually the software insisting that a “Doctor” wasn’t either Male or Female. The conversation up until here had been that Optus hadn’t considered it possible that a female could be a doctor and were enforcing data validation rules in the platform to ensure nobody accidentally added a “doctor but it’s a girl” to the platform which would cause some sort of problem, so when this was ruled out everyone sort of calmed down a bit.
But there’s still a problem here.
In the midst of the social media outrage programmers got a bit of a bad rap. The rhetoric was that someone sitting at their desk with the instruction “make a loyalty club platform” had typed the commands into his (probably his, *tsk*) computer and taken the initiative to protect the platform from obvious data entry errors like female doctors or engineers and male stay-at-home parents. That’s not how this works, it’s not how any of this works, but groups of people did sit in a room and draw up what checks and balances should be done on what people were entering into this screen. The developer made a mistake where the rules described to them got misapplied, but why are there rules? Why is gender even validated against anything at all? They’re not the majority but there are certainly people who feel more comfortable and real doing things the software has been put together to stop. There are even plenty of people who don’t feel right being described as “female” or “male”, so even if we’re not validating this field against others we are restricting it to one of two options (and it has to be one, see the “*” next to it? Means mandatory). Sure, the validation’s broken — why is there validation? There’s a non-zero amount of people that reject these concepts as they apply to them, or take from them in parts. It even shifts over time.
Then there’s this;
This one’s blown up this week. Basically a handful of political customer relationship management systems during the election have been instructed through a string of not-great decisions to make a massive assumption. They yank enormous piles last names from males, with their first initials and addresses, from a database, then address a letter to them and the female of the house, using the last name of the male.
This… this is not how this works. There are a relative handful of people who need our support through us using words and combinations of attributes that they feel identify them (therefore they do). There’s not a handful of women who aren’t correctly addressed by the first initial of the name they were given at birth, and the last name of the man they are living with. There’s heaps of them. Shit-tonnes. The idea of the “lady of the house” assumes so much not only in terms of marital status, but even in just if the traditional adoption of taking the husband’s last name has been used. My wife of ten years hasn’t adopted my name (except once or twice where it was a choice between the guy taking the phone pizza order understanding who was ordering versus exercising her identity). This stuff isn’t that hard, but we make it look really, really hard.
The actual rebuttal for why validation runs is interoperability. A fairly small portion of any value from software comes from the purpose that’s obvious to its users. Optus’ loyalty program isn’t super useful to it that way in 2016, you don’t increase shareholder value by having people’s names in a system and giving them iTunes vouchers periodically for buying stuff off you — there’s not even any bottom line revenue in understanding if the voucher should be blue or pink. In modern business (and in modern software engineering), an enormous amount of apps need to describe you to other apps.
Optus’ loyalty program database is of peripheral value to understanding customer loyalty but worth a pretty penny to data aggregation services that sell lists of customers to other businesses entirely who want to target advertising. These businesses want to know who might be interested in e.g buying baby clothes for their upcoming second kid — with the strict caveat that the data they’re buying has to reveal that information in a traditional way to be any more valuable than a list of pure email addresses. Homogeneity in how we treat people is required for shopping your data beyond its initial value proposition of “a list of people who are our customers” and realising its value as “a list of people that other business’ systems know about, can consume in structs that interface with other internal systems, and allow us to reduce people to a set of key/value pairs that are the way we’ve been understanding humans forever.”
I’d like to personally see the end of customer slave markets where the customers don’t even know they’re for sale. This boxing of people into firstname=Bob,lastname=Smith,birthdate=19710311 (don’t have a last name? Have two? Don’t care.) is actually making business worse. It’s a soft option as an alternative to making things that people want to buy and use — selling info about people who wanted to buy and use your things before to other businesses who want to sell them things now. It’s the primary reason for sanitising people in tech driven businesses (other than business analysts who just like lots of rules and learned this is how you do it in uni, in 1991) and I not only want to sunset it, I want to actually actively push back the other way.
What if…
What if, just bear with me…
What if along with the people who describe the problem, and the people that validate it, and the people that check the validated problem is solvable with technology, and the people that break the problem into bits that are solved with bits of technology, and the people that write the code that make up those bits that do it, we had someone that checked if we were making people feel like shit along the way?
There’s already people that double check this problem solving is legal (legal), people that check you’re not invalidating your license to participate in the industry by doing it (risk and compliance), that you won’t look like crap to the majority of your customers who don’t care about edge cases like gender value matching and name validation (marketing and brand), that you can actually afford the effort because there’ll be revenue on the other side (finance), that we have the time and people to do it (program/project management)… What about someone who just checks whether nobody sits there going “stuff this, another day not fitting in a web form.” We could call it a diversity function.
What about someone who is in the meeting looking at the whiteboard upon which is “Dr ≠ woman” and they say “Hang on, what value does this provide?”
What about someone who has been in the meetings since project kick-off who is not only likely to have a problem with a Powerpoint slide that says “Everyone is either a man or a woman so we are going to get the programmer make sure the system enforces a selection”, but whose literal job it is to stop that dumb decision?
I think we should make inclusiveness part of enterprise software design. It should be a role. I think it’s a measure of us as reasonable people that for all the cogs and gears that churn out functional software, someone’s jobn was to think about who might feel excluded by it. For years we’ve handled (ok, poorly, but we’ve handled) the assumption in software that people can see or hear, that’s even addressed in literal US Department of Justice guidelines. Can we stop assuming people fit other moulds too?
Who’s in?
