Let’s start with a definition of software ethics:

“Software engineering ethics studies the interactions of human values and technical decisions involving computing”

For this topic I want to look at algorithms. For me algorithms can be quite annoying when browsing the web. When pretending to know and predict what you like, no harm is done by recommending the wrong shirt or vacuum cleaner. But when an algorithm suggests that a certain picture was the highlight of someone’s year, this can be a great moment in time or it might represent someone’s greatest grief. Kate Every did a great talk on Design Ethics during Inclusive Design 24 describing a situation where the Facebook algorithm suggested that a certain picture was the highlight of someone’s year. Only this picture was of his daughter that sadly passed away that year. By no means the functionality Facebook had in mind, but when you don’t take the unhappy flow into account, your feature might change into a curse instead of the blessing you want it to be.

Identifying this challenge is hard, so solving it might be even harder. In my opinion the opposite is the case. If we just take a step back and would have asked this specific user whether the assumption of the algorithm did was correct, a lot of grief would have been spared. That of course is just this specific use case. We should try to work to aim for a more structural solution and identify software ethics challenges early on in the development process. This is harder to do, but if we try to create more diverse teams more of these “edge cases” will be identified during the normal development cycle.

Software design in the context of being inclusive is a huge topic to discuss, but for this blog I will focus on the cultural part of software design. The reason for this is that while co-hosting at Inclusive Design 24 I co-hosted a session with Linda Keating on Making the web a more welcoming place for minority languages. Coming from Holland this is a very interesting topic and I thought I understood most of these challenges. But I definitely did not, and there is more than meets the eye.

So what if we have a multilingual website where you can choose your language? Pretty straightforward right? Just put a logo of the flag for the language you want to choose, for example the Union Jack for English. But what if you are from Ireland and you do want to read the site in English, but to get there you must click the icon of the coloniser’s flag. This can hurt each time you have to do it. A flag is not equal to the language. We as software engineers should be more aware of this. The same goes with forms. We have a habit of forcing our own cultural standards on everyone who needs to fill in the form. The concept of length in a name field. Names cannot be too short or too long or can contain characters that are not supported by the parser.

These are all things that can easily be solved if we just try to identify ourselves a bit more with our audience. There are some easy alternatives on language selection, like using text instead of flags. Some best practices can be found here.

For this final topic I want to dive into how software is used on the web. We want to make our functionality available throughout the world, but our standard user is not the person sitting in a coffee shop using their state of the art laptop. Looking at the Internet users by continent in the table below, you can see that Asia is by far the largest community. Another fascinating thing, Africa is rapidly moving to a second position. But most interesting is the penetration rate. In the coming years a huge growth is expected.

But why is this a topic for software usage? Like I mentioned earlier, the typical internet user and their behaviour will change. For example, almost 75% of the users in Africa use the internet on a mobile device, compared to less than 50% in Europe. So we need to take this into account when we design our applications to be mobile first. Also using the internet on a mobile device does not mean a user is always online, especially in regions with less coverage or where the cost of mobile data is high. We need to address this from an architectural point of view and make sure that we build our software with an offline first approach.

In this blog I only touched the surface of some of the challenges that are out there to make our software more accessible and more inclusive. I also highly recommend looking at all of the sessions of the Inclusive Design 24 conference of 2022. You will be amazed by the topics discussed and insights you will gain.

For me, the most important takeaway is that even if we think we are developing with the right intentions and aim to be inclusive, we still can take a step back and look at the diversity of the group of people involved in this process. Besides that, we can always use the knowledge of our users and be open to feedback and handle this in an adequate manner.

But most of all it’s about being more aware and open minded. This reminded me of a quote of one of my all time heroes Michael Jordan. Even if we do things time and time again in a certain way and this is not the right way, we need to go back to the basics and change the root cause and not try to fight the symptoms.

Erik